ASP.NET MVC 2 Architecture and LINQ data model

Question

I am creating my very first larger ASP.NET MVC application. After thinking about the application architecture for some time, I thought I would hear some other opinions.

I am using LINQ-SQL for my data layer. However, I am not planning on using the LINQ objects throughout the application, since I would like some more specific data types for some fields (ex I would like Url fields to be of System.Uri type, not System.String). It also seems that pasing LINQ objects around is not a very good idea since the DataContext may not always be available. I would absolutely like some comments on this.

I have created some more specific objects to represent my data. The LINQ objects can be parsed to these objects, and I have created some DataClient classes that utilize the LINQ DataContext to retrieve data which is then parsed to my custom objects and returned. This allows for using LINQ-SQL as the data layer only.

Now one complication comes to mind. How to update object values in the database. I am still debating whether to use my custom objects (thus requiring relevant properties to have setters) as argument for an update method. If I take this approach I am planning on making the Id : int property a nullable type, and only have the ability to set the Id property when LINQ data objects are parsed to custom objects. I think this makes sense, since the database is the only place identifiers are actually assigned.

This approach will not let me update records without first retrieving them from the database, even though I know the Id. On the other hand I could make update methods that will take every field as a parameter. However, this seems to be a lot of double code.

Now for the MVC model. I am not sure whether to use my custom objects directly in the views, or whether to create yet another representation of the same object for use in the ViewModel. Initially I thought it would be nice to use the same object, but then questions started appearing. What if the view requires other features of the model (ie. What if I want the view to render something controlled by the controller, but not dependent on the data-model. How would the controller tell the view what to do?)? Also, I would very much like to use the DisplayName and validation attributes available from the DataAnnotations namespace. If I want to localize this data, where would I put the resources (the custom data objects will not be in the same assembly as the website) Also, I would like to be able to use the objects in other (not web)applications?

I am looking very much forward to hearing your comments.

Answer 1

See http://nerddinnerbook.s3.amazonaws.com/Part3.htm for guidance about using repository objects to properly manage the Linq to SQL data context.

See http://nerddinnerbook.s3.amazonaws.com/Part6.htm for guidance about using ViewModel classes.

For ASP.NET 2.0 specific information, such as Data Annotations, your best resource is probably this book: http://www.amazon.com/Professional-ASP-NET-MVC-Wrox-Programmer/dp/0470643188/ref=pd_sim_b_2

Answer 2

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.

Answer 3

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.