views:

197

answers:

2

Hello everybody,

I am having a difficult time understanding two design approaches in terms of long time extensibility in my current ASP.NET MVC application.

The ORM that I use for providing data is Linq2SQL. Which is just amazing to work with, BTW!

Now I am having some trouble with the design of my model classes for my views. Currently I've got a partial class for each entity in the database.

  • This approach allows me to extend the class without having to switch the strongly typed model on my views
  • I can easily add further properties for extra data (mostly meta)
  • I can easily add helper methods which populate lists for me and/or do other data transactions
  • One problem remains:
    • I can't create a custom constructor as this is already managed by Linq2SQL

After reading the ASP.NET MVC Book and some tutorials, I see a very common use of FormViewModels for providing extra data on an object.

Currently I am very comfortable with the partial class design for my entities. But I wouldn't mind switching the design as I am still building the application.

What are the benefits of the FormViewModel instead of an easy partial class approach and what are the best practices in this matter?

All help is more than appreciated!

+1  A: 

As with so many things, it depends. If your app is small, and you have a one-to-one relationship between what the user sees, you may not need view models. You can expose your models directly. Most apps are small apps.

As you application, specifically your UI, grows you may find that you want a greater separation between the data-tier model object and the presentation-tier model object. That's where view models come in. Even though the properties are the same (i.e. User has FirstName, LastName, EmailAddress, etc.), the methods and requirements of the models are different. View models let you adhere more closely to the Single Responsibility Principle.

Please don't believe that it is some cardinal sin to not use view models. No one in the Rails world uses view models. (At least that I could find. And Rails is a dynamic language, so that changes a lot of the rules right there.)

Jarrett Meyer
+1  A: 

By using the partial class approach you force your domain model to know a lot about your ui. So I would say its considered bad practice to use such a approach. When your application grows it can be quite a mess to maintain. And what happens if you have a view that needs to represent data from two totally different models?

Using viewmodels is a very common pattern and it has been proven to work quite well. However, there are different ways of using this pattern. You can ether use viewmodels that contain your domain model objects. Or you can create totally separate viewmodels that only contain the data that they need to display and none of your domain model. If you use that approach you will end up with a lot of mapping code. Here I would suggest you use automapper which will help you a lot.

Mattias Jakobsson