CODEWITHSUNDEEP
asp.net-mvc
Kamarey
Kamarey

Reputation: 11079

MVC: Should model inherit from BLL object or containt it?

What pros and cons for:

  1. Use BLL as model.
  2. Model inherit BLL.
  3. Model contain BLL.
  4. Model has only fields that are going to be used by view.
  5. Something else.

Background: I have some heavy BLL class with about 100 fields. I'm going to show some of them in a view. How a related model should look.

Upvotes: 2

Views: 1297

Answers (4)

Tom Clarkson
Tom Clarkson

Reputation: 16174

I think the best approach is mostly a combination of 3 and 4, using whichever is easiest for a particular view.

Where the bll object is exactly what the view needs, you can use it directly. This doesn't come up much though, as you almost always need something else - values for a dropdown, names instead of ids, etc.

Where the data object is very close to the view, I have it as a property of the model object. That way my controller can jsut set model.DataObject instead of copying properties individually. On edit forms you need to be careful that your view contains fields for all the data object properties (obviously not a good choice if there are sensitive fields), but it is perfect for read only views.

For more complex views or those that don't really map well to a single data object, use a custom model object and copy the properties you need so you have complete control over what is included and can keep the view code simple.

I have tried using inheritance, but that really just gets you the worst features of all the other approaches.

It's also worth noting that you can quite easily switch to a different model if you need to - with strongly typed views any mismatches are easy to find and fix.

Upvotes: 1

Darin Dimitrov
Darin Dimitrov

Reputation: 1038830

No pros, only cons for all those approaches. The best approach is a combination of 4 and 5. It is called view models. So create a view model for each view which contains only the fields this view needs and map between your model and the view model. This mapping could be facilitated with a tool like AutoMapper.

Upvotes: 8

rsenna
rsenna

Reputation: 11963

First, let's make some assumptions clear.

The "ASP.NET MVC" is based upon a proven standard, known as the "Model-View-Controller" architectural pattern. This is not a new invention from some Microsoft geek; quite the opposite, this pattern has been used by several frameworks since 1979.

So, what is "the model"? Using a more modern term, it is the domain logic. It is your business entities, your data access objects, even some of your static declared enumerations and collections: anything that is used by your application, has business value and is not related to some specific presentation issue or requirement.

That's why I said your question, deep inside, does not make much sense.

After you tried to explain what your question is about, and after jim and Darin Dimitrov answers, I guess what you really need, what you are really asking about, became a little clearer: what you want to know is how to bind your existing, pre-MVC business layer with the C and the V of an ASP.NET MVC application.

So, if you do have a well designed BLL layer, and, more importantly, if your BLL and DAL communicate through some DTO's, you could, theoretically, bind them directly to your views.

If those DTO's need to be transformed in some way (because they could not be directly understood by the end user, for instance), this should be done by the use some "ViewModels", which are basically another set of presentation specific DTO's, plus data-annotations for server-side data validation. This transformation, of course, should be done by your controllers.

Some MS people will say that you MUST use viewmodels, and that if you don't use them you will rot in hell. I do not entirely agree. Of course, there are several advantages in using view models (like the already mentioned data-annotations, compile-time verification, intellisense and so forth), but if many other successful MVC frameworks are fine without them, I don't think it should be different with ASP.NET MVC.

That's my 2 cents.

Edit Another important advantage of using viewmodels is related to security: by exposing a set of presentation-only DTOs, the real domain-objects become somewhat protected.

Upvotes: 3

jim tollan
jim tollan

Reputation: 22485

Kamarey,

You can safely use your exisiting BLL (if it satisfies the business needs). You then simply need to identify the discreet sections in your views that you want to update and create ViewModels for those. You may find of course that there are some instances where you can strongly type your exisiting BLL model down to the view. i.e, e.g. etc..

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" 
    Inherits="System.Web.Mvc.ViewPage<IList<yourbll.model>>" %>

In short, i think you'll need to analyse the needs of the views in relation to your BLL.

take a look at this SO question for inspiration on the ViewModel:

ViewModel Best Practices

http://stephenwalther.com/blog/archive/2009/04/13/asp.net-mvc-tip-50-ndash-create-view-models.aspx

http://www.highoncoding.com/Articles/659_Implementing_ViewModel_in_ASP_NET_MVC_Application.aspx

Upvotes: 1

Related Questions