Question

I have a partial view that loops through its Model (a list of things) to show the thing.Name and three integer values that are counts of related entities.

First of all, I tried putting: (pseudo-razor)

foreach(thing in Model){
    @thing.Name : 
        @thing.related.entities.where(condition1).Count()
        @thing.related.entities.where(condition2).Count()
        @thing.related.entities.where(condition3).Count()
}

But its really slow… so I created a function in the ThingRepository that does same queries faster, something like this (pseudo-code)

function GetCountofRelatedEntities(relatedID,condition){
    return db.entities.where(relatedID==relatedID && condition).count()
}

and its much faster, so I want to call it. I think I should call it from the controller, but then I need a ViewModel to keep a (thing, int, int, int) collection as the model, or I can use the ViewBag extremely to pass the results to the view, but, and here is the question:
Why not simply use the repository from the view? whats wrong with this code in the view? (pseudo-razor)

@repo=new ThingRepository()
foreach(thing in Model){
    @thing.Name : 
        @repo.GetCountofRelatedEntities(thing.relatedID,condition1)
        @repo.GetCountofRelatedEntities(thing.relatedID,condition1)
        @repo.GetCountofRelatedEntities(thing.relatedID,condition1)
}

Could you tell me why I shouldn’t instantiate the repository inside a View? Or I can do it?

Answer 1

One purpose of the MVC pattern is to provide a structure that fits a wide range of common programming situations. To simplify:

• Model: Describes the shape of your application, i.e. the parts of your software specific to your business.
• View: Display the data to the user and transmit user events to the server.
• Controller: Acts as a middleman between the view and the model.

What you’re proposing “works,” in the sense that it gets the data on the page where you want it. In the short term, it appears to be saving you time and effort, as you don’t have to bother with controllers, viewbags, etc.

However, you are breaking the MVC structure in a way that you will probably regret later on. For example, say in a few weeks your boss comes to you and says, “Hey, you know that page you added to display that list of entities? We need to do some filtering and sorting on it. And I need it yesterday.”

Now you’re faced with a choice: Do I add this filtering logic to my view page and meet the deadline, or do I take the time to move the data access code to a controller and rework my view, at the risk of missing the deadline and breaking what’s already working?

You’ll probably take the easy way out and add the logic to the view, and now you’ve got a growing mess on your hands. We’ve been down this road with VB6 and Webforms apps with 6,000-line codebehind files. Trust me–you don’t want to go there.

Another problem is that the MVC structure is well understood by the programming community. If someone else comes along and tries to work on your code, you’re making it harder for them by deviating from the conventional approach.

The MVC structure is time tested and sound. Until you fully understand its purpose and the benefits it provides, try to follow it closely. It’s not a good idea to break the rules until you have a firm grasp on them.