I have an understanding of the basic MVC design pattern.   But I have a MVC design question.   I have 15 simple gridview and details view screens that I am thinking about refactoring into a single (complex) screen that uses a treeview to do a drill down.    I know that I could do one call from the controller to the view to display this screen.  

The basic MVC pattern has the controller calling the view once and the view handling the display of the viewdata.  But what if we have a very complex object that we want to access through lazy loading invoked only when needed by the view?   How should the view invoke the Get<details>  on the controller?    

 Second question.  If this can be done, should it be done? (i.e. should the view invoke the controller for calls or should I just place the Get<Details> calls in the code behind of the view?  (or course the Get<Details> is just a call to the BLL so no model work is being done in the view.....

 

Interesting. The line between what we should do and what we can do gets blurred a lot of times by either our manager or the person paying the bill. In this case, however, I think you can get the effect you want by using Ajax calls (perhaps on the nodeclick event?) when drilling into your different views. There are some good examples of using jquery Ajax calls with the MVC framework floating around.

As for your second question, the view is technically always invoking the controller to render other views. I think to preserve the separation of layers, the controller would need to call a method in your datacontext to get the data you want, then pass it back up to the view. Maybe I'm just rationalizing things, but I don't see any other way of doing it.

The view should never call the BLL or the Controller. Ever. I fell into this trap when building my Components. It made my Controllers untestable.

bcsmith100:

should the view invoke the controller for calls or should I just place the Get<Details> calls in the code behind of the view? 

Neither! No way. Absolutely not. 

Lazy loading is different (slightly). The controller is giving the View an object which will *Automatically* fill in the blanks, only if the View asks for something that's blank. The View shouldn't call anything other than ViewData.PropertyTheHasntLoadedYet. It's your object which has the logic for loading the data.

public IList<Cake> Cakes {
  get{
    if( this._cakes == null )
      this._cakes = BLL.GetCakesTheHardWay();
    if( this._cakes == null )
      this._cakes = new List();
    return this._cakes;
  }
}

So, initially Cakes hasn't been loaded because it takes too long and we only want to load them if needed. So, if someone requests Cakes from our object, but they haven't been loaded yet, we do the hard work to retrieve them. And if someone requests it again, we just returns the saved list. This way we don't have any calls to the BLL in the View.

However, I prefer to explicitly specify which parts of the object to load, so that I get back a static object that doesn't "do" anything.

Some people might say that lazy loading is still "Calling the BLL from the View" and technically I agree, even tho it is indirectly. But I think that's ok, because it's out of the View's control. However, I don't think a View should directly or indirectly call into a Controller, EVER. But that's just my honest opinion.

Thanks for validating my assumption....but I still have a question.   Say I don't do lazy loading...but instead just retrieve the top level object with nulls for arrays of sub-objects (and sub--sub-objects)....there is a lot of object nesting going on here....

and then say that I want to trigger the next layer of object loading when requested by the expansion of the tree node (i.e.   Products->Orders->Order Details->etc...)

 I don't see how the view can trigger the load of the object without going either to the BLL (which I figured was wrong) or the controller which also shouldn't be done????  

I know that this falls under AJAX where we are partially loading data and calling directly to backend services...but I don't understand where to map the AJAX calls for staying within the bounds of the MVC pattern....some how when the tree node expands I need to trigger more data from the controller....how do I trigger this data from the view to the controller... I am not being entirely clear here because I am a little confused... please excuse this...I too have had problems in the past with presentation and controller interaction that corrupted the design and I want to understand how it should be done in asp.net mvc.  

I'll have to defer to tgmdbm. Admittedly, I tend to be more of a 'get it done' type of guy, so the solution I proposed earlier probably isn't the best way to do it, although it will get it done. I would be interested in hearing alternatives.

 Based on your answers I have been looking for how to handle the controller - view interface for an AJAX treeview.    Originally I was confused about how to consolidate the controller interface...with some methods being invoked through URLmapping to the view and other methods being called by directly by the ajax functionality.   I was thinking about the ajax - web services design....where the controller exposes a web service (kind of)......I have found examples of people who are doing this now with Ajax and asp.net mvc....this doesn't seem right to me...but it may be the correct thing.   I have also found examples where people are using multiple  forms on  a page...and then using a form around the individual  control.     So I  am still a  little confused.....unless I can figure out something different it looks like what VinBrown suggested is the best thing...which is having the ajax treeview call the controller as if it was a web service.....hopefully this is something that MS will work on and it will become clearer what we should do.....does anyone have any input to clarify this?

bcsmith100:

I don't see how the view can trigger the load of the object without going either to the BLL (which I figured was wrong) or the controller which also shouldn't be done????  

There's a difference between the View calling the Controller like <%= new MyController().DoSomething() %> which is evil, and using AJAX to access data on the server, which i think is what you're after. something like:

<a href="Products/1234?format=json" id="getProductLink" style="display: none;"></a>
<script type="text/javascript>
  new Ajax.Request( $('getProductLink').href, { onSuccess: function(response) {
    alert( "yey" );
  } );
</script>

The above is using the prototype framework.

So you build your URL's as per usual, I'm using a hidden <a> tag to hold the URLs instead of putting them in the javascript. I've got some logic in an ActionFilter which takes the format from the query string and renders either html, json, or xml. This way I can use response.responseJSON (another prototype helper) to directly access the json object returned from the request. I then use that to build the details view of the whatever it is, in this case a Product.

Some people will say it's better not to build the view in javascript. They'll say you should have a controller action which outputs just the html for the details view and use something like $('productDetails').innerHTML = response.responseText;

It doesn't really matter, the mechanism is the same. You should find what suits you best and go with that. 

 thanks to both of you...I now think I have an idea of what to do....now I just need to figure out implement the ajax treeview...which is my next action.   One last question to you tgmdbm if you don't mind....I have read your answer to other posts about creating sitemap menu's that enforce roles (something like we have now in CSSFriendly....... want you said and want I have found so far is that everyone is basically on their own for now...that we have to do our own HTML extension to handle this ..  have you done any more work on this or is this still the case?   I noticed that in ScottGu's tutorial he said eventually MS would get a full set of controls and helpers..... I would hate to spend time on something that is going to be in the next preview....has anyone heard when MS will get something like this? ...... just curious.

Did you really mean to mark your own post as the answer?

Yeah, there's no MvcSiteMapProvider out there yet, and i haven't needed it yet so I haven't implemented my own.

If you want to wait i'm sure one will crop up some time. But yeah, we're on our own with this at the moment.

 I had realized that I was marking a specific entry as the answer.   I thought I was just marking the topic as "answered"...hence I just used the last entry as the closing answer.   Thanks for pointing this out to me.

I was not sure if I should have started a new thread on this or not, but I have a very similar question... I have a similar complex object that I am using in an MVC Webpage. I am storing this object in the Session and passing it to the View via the controller... but I am having an issue with what is the best place to be saving this object back to the Session (and even, when the time comes to the database) when it changes.

Since I am accessing the Session object in the Controller and not in the View, it doesn't seem quite right to be saving the object's state to the Session directly when it changes. I know I don't want to be accessing the Controller directly to try to do this, but that almost makes sense just because the Controller is where I originally access the object to pass to the View. The other possibility I considered was to have some sort of a wrapper class for the Session object and perhaps use that class to save the state and pass it from the Controller to the View instead of the object from the Session. Then I could just invoke a "Save" method in the wrapper and call it directly.

 Most examples of the MVC Architecture I have found on the Web are simple things that just post the data to another ControllerAction but there is far too much data within this object to make that feasible. Just wondering how best to approach this. 

Thanks ahead of time for any input you can offer.