See for guidance about using repository objects to properly manage the Linq to SQL data context.

See for guidance about using ViewModel classes.

For ASP.NET 2.0 specific information, such as Data Annotations, your best resource is probably this book:


I have chosen in my MVC 2 applications to use the LINQ to SQL interfaces to select SQL directly into my business objects rather than use IQueryable or IEnumerable as anonymous classes. I select everything into new List and in the select I specify which column is translated into which property/field in the class itself.

So for something like the uri, I would select the string from the database into a string field in the class that would be used by the MyClass.Url property to create a System.Uri.


Although I use a different technology (Silverlight), I am facing a similar problem.

I am still searching for alternatives, but just like you I find it best to use custom objects for all my data, instead of those generated by Linq-to-Sql. I use these custom objects as shared objects (with WCF or some web service, duplicated on the server and client side). On the server-side I manually copy these custom objects to the generated Linq objects for insert/update/delete (in a single method for each, not duplicated all over the place). On the client-side these custom objects are shared for binding with the UI. (The nullable ID in the custom object which you mentioned would still be useful.)

I know, creating duplicate custom objects feels like a lot of additional work, but the current state of the generated code does not allow for most of the specialised features that I need (e.g. Uri vs string, adding additional properties, removing redundant DB-specific values). I am busy researching MVVM and the Entity Framework, but, although they do some things better, they still provide the same basic challenges.

I hope this helps.


It seems like the repository pattern is a good option for both these scenarios, anyone concurr?

Related Articles