CODEWITHSUNDEEP
asp.net-mvcmodel-view-controllerseparation-of-concerns
Fergal
Fergal

Reputation: 2474

Separation of Concerns, Business logic vs Presentation logic

In MVC or in general, when trying to separate business logic from the view, how far do you go in terms of removing logic from the views? Should a view have zero logic? Should there be multiple static views with simple "holes" that variables fill, or can we have a single view that can output different html depending on the situation?

<html>
    <body>
        <h1>Your name is @uname</h1>
        @if(account<3000) { 
             <p>You are an ok customer</p>
        } else { 
             <p>You are a great customer</p>
        }
    </body>
</html>

Is the above OK, or should there be two views, one for an OK customer, and one for a great customer?

Upvotes: 3

Views: 1540

Answers (4)

Jaimal Chohan
Jaimal Chohan

Reputation: 8645

Regardless of your technology stack, what you are essentially saying is that a Customer is good if their account is less than 3000, else they are great.

So the Customer State (swap this out with a better word, AccountState?) can either be Good or Great.

The State is thus a facet of Customer and should be a property/method on the Customer.

Upvotes: 0

tereško
tereško

Reputation: 58444

In classical MVC implementation the view would contain presentation logic. The MVC design pattern is composed from two layers: model layer and presentation layer. Views and controllers make up the most of presentation layer, where controllers handle user interaction and view deals with user interface.

Since you actually cannot (well .. you can, but in practices it is semi-impossible) implement the classical MVC pattern for web applications, in ASP.NET MVC framework you usually have two ways to approach this:

  • Rails-like: you push the presentation logic in the controller and leave templates with almost no logic. But i would sat that it's a bad choice, because the issues with rails implementation.

  • ViewModels. This structure lets you contain presentation logic separate from controllers. It actually is a bit misnamed, since ViewModels, as described in ASP.NET MVC documentation, actually are what classical Views should be. You put the presentation logic in ViewModel instances and use you "views" as templates, which now can contain a little presentation logic as possible.

Upvotes: 0

YavgenyP
YavgenyP

Reputation: 2123

Having an extra view would be wrong, in my opinion, as it would lead you to duplicating html code in many cases.

With the sample you provided, I'd stick to using an if..else block within the view, while having only one <p> eventually, and setting its text in a variable. something like

 @string text = account<3000? "you are ok":"you are great";             
 <p>@text</p>

Of course, theres also another solution: Extending your model with a ViewModel class, which would have a TypeOfCustomer string property, with this relevant text.

To sum it up, i dont think its "illega" to have such blocks in the views, to set up the correct html. As long as the differnece between the cases is smaller than the shared code, theres nothing wrong with havnig one view with if..else blocks.

Upvotes: 0

Mike Simmons
Mike Simmons

Reputation: 1298

It's fine to have some basic logic in your views, as long as it's only concerned with the presentation of the data you are displaying. I would probably change your example to remove the definition of an "ok" or "great" customer and set this earlier, in the model.

Saying a customer is "ok" if account<3000 should be defined in your business logic, wherever that might be - model or business tier, where it can be unit tested and re-used. You could then use a customer status enum in your view to perform this switch in markup:

if (@Model.CustomerStatus == CustomerStatus.Ok)
{
    <p>You are an ok customer</p>
}
else
{
    <p>You are a great customer</p>
}

Upvotes: 3

Related Questions