2

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.

Kamarey
  • 10,832
  • 7
  • 57
  • 70
  • The way **I** see it, both the data access layer and the business layer are part of "the model", so your question does not make much sense. Maybe you're asking about business layer vs. data access layer...? – rsenna Jan 10 '11 at 12:44
  • No, BLL uses DAL internally, so the question is about the mvc model and BLL, and how exactly the BLL is part of the model. – Kamarey Jan 10 '11 at 12:47

4 Answers4

8

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.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • 1
    Can you add some explanations why do you think so? What problems do you see, say, in approach 1? Why this is bad? – Kamarey Jan 10 '11 at 18:43
  • 1
    Because models are usually not adapted to view requirements. There will be many properties that you don't need, won't be formatted as it should, will have missing properties which will lead to writing ifs, loops, etc.. in the view to get the correct formatting. Also when using models as input to controller actions validation attributes won't work because half of the properties won't be required in this view but because they are marked with the Required attribute validation will fail, there is a risk of what is called mass property injection so you need to explicitly (to be continued...) – Darin Dimitrov Jan 10 '11 at 18:48
  • 1
    exclude/enclude properties from binding, and the list of cons goes on and on. And by the way the same cons apply to 2 and 3 because you are still using models in your views. 4 is the way to go: use views models - classes specifically tailored to the needs of the view, containing only the properties required by the view and properly formatted and which contain validation in the context of the given view. – Darin Dimitrov Jan 10 '11 at 18:49
3

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.

rsenna
  • 11,775
  • 1
  • 54
  • 60
1

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

Community
  • 1
  • 1
jim tollan
  • 22,305
  • 4
  • 49
  • 63
1

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.

Tom Clarkson
  • 16,074
  • 2
  • 43
  • 51