I think the key is to have your data access tier modular enough so that it can be used in both the controller and the view-preparer. There are valid use cases for both. The best solution usually depends on the way your site is constructed.
If it is content-centric usually your controller fetches the data and then view preparers transform the parts of the data they are interested in to the appropriate format for the view. If you are using tiles to provide reusable modules for things that are dependent on the main content of the page in which they sit to provide some id or key that they need to look up their data, then the view preparer is a good place to do the data access for that part of the page. On many of our sites we hit multiple data sources to create a page. The main data access occurs in the page controller and then view preparers are used to transform the data as needed for the main section of the page and also to fetch other related data for things like ad and reporting calls, associated content and site headers/footers. Rick On 10/29/09 7:42 AM, "Antonio Petrelli" <[email protected]> wrote: > 2009/10/29 anyz <[email protected]>: >> Thanks a lot. Your comments are very helpful. I believe with view data you >> mean that is kind of static data not tied to business logic. For example >> menus soemtime are dependent on Roles and/or business rules. In that case >> menus should also be loaded from controller. Is it correct? > > In fact I believe that menus are *always* view data. Even if they are > dependent on business rules, they should loaded where they belong as > they do not make sense in other parts of the page. > Obviously IMHO. Ask your project leader (if you're not him/her :-D ) > because this is an interesting point of discussion. > > Antonio
