views:

62

answers:

3

I have a Linq-to-SQL entity that I will be serializing and returning as JSON over a webservice call.

There is one property on that entity that I would like not to be serialized. For this, there is generally the [ScriptIgnore] attribute, which works exactly the way I want if I manually add that to the designer.cs file.

Now, since the designer file is automatically generated, I would prefer not having to manually edit it, as any changes could easily be overwritten. My question is thus: is there any way to annotate the property so that it is excluded upon serialization, directly in the DBML editor?

If the answer is no; are there any solutions to this that are neater than manually setting the property to null before serializing it, or returning an anonymous type identical except for that one property? In MVC.NET, is there any way to pass parameters to the JSON() method to modify its behavior, perchance?

My apologies if this has been asked before - I'd expect it to be a common question, but I couldn't find anyone like it.

+2  A: 

All the DBML generated classes are partial classes so that you can extend them in another file. The DBML designer will only alter classes in the Designer.cs file. Remove the property from the DBML designer and put it in a partial class in another file. You can then add whatever extra attributes you wish and the DBML designer will leave it alone. You will have to manually manage this property and update it to match any database changes but i think that is probably a price worth paying if it solves your problem.

Ben Robinson
Heh, I didn't even consider that option. I guess it comes with its own cons of having to manually maintain it, and having to copy some rather bulky and usually machine written code to connect it to the ORM logic. If there was a way to do partial *properties* and just extend them with attributes, I would totally settle for that. I guess I *could* live with this, if it's my best option. +1 for now, but I'll leave the question open to see if anyone has any brilliant solutions =)
David Hedlund
All you need to maintain the ORM mapping is maintain the column attribute decorating the property. Al the rest of the generated code is bolier plate that wires up some events and partial methods. If you are not using the events or have not implemented the partial methods you can safely remove this code and it will have no effect other than to remove your ability to use them later. Once that is done you are managing a fairly simple property and a fairly simple attribute.
Ben Robinson
@Ben: `SendPropertyChanging` and `SendPropertyChanged("Name")` are still needed in the setter, for the ORM to notice the new values, and thus to perform an update upon submitting changes. Given that, the `if(BackingField != value)` check is probably also desirable to keep in there. So sure, I can remove the optional hooks, but I still think it looks rather bulky. Still, this seems like my best option yet. I'll probably accept this unless something more promising comes up.
David Hedlund
+1. Very clever.
Steven
accept. this is what i ended up going for. cheers.
David Hedlund
A: 

I would advice you to create special DTO's for this matter. This allows you to have full control over the output, because even when you add another property using a partial class, the original property that you want to ignore will still be serialized.

Steven
I didn't recomend adding ANOTHER property, simply moving the original property from the designer file to another file and adding the extra attribute. If you create a DTO and serilise that you have to then maintain your mapping between the DTO and the Linq to SQL entitiy to match any changes to the database. By simply moving the property to a partial class you only have to maintain a sing le propertymanually, the rest you can just do in the designer.
Ben Robinson
@Ben: This is a very clever solution.
Steven
+1  A: 

If you will have no success with partial classes (which is probably the best way), then you can just serialize the date yourself. It is known that ASP.NET MVC use JavaScriptSerializer to serialize the data. The JavaScriptSerializer have simple and nice customization features like JavaScriptConverter and you can very easy convert the object in something less standard (see http://stackoverflow.com/questions/3226568/use-attr-tags-for-json/3228858#3228858 for example or all other topics).

To be the most conform to the standards you can define a class derived from JsonResult (for example like here http://stackoverflow.com/questions/758879/asp-net-mvc-returning-jsonp or http://dev.qsh.eu/Blogs/Dmitry-P/January-2010/ASP-NET-MVC-Tip--3.aspx) and save serialized data in context.HttpContext.Response directly with a Write method. Then you are absolutely free how you serialize the data to JSON.

Oleg