To get the benefits of the MVC pattern the view's sole concern must be transforming the data it is passed.
Alan's suggestion, RenderAction, is a slight violation of this. Conceptually, RenderAction builds two views in parallel and then merges them. In practice I have found that pure MVC does not work well for composite interfaces and RenderAction is the best compromise. Your technique completely violates the design of MVC by having the view pull data. The downside is that you have lost the nice separation of concerns and testability. On Tue, Jul 13, 2010 at 11:24 AM, silky <michaelsli...@gmail.com> wrote: > On Tue, Jul 13, 2010 at 8:44 AM, Trevor Johnson <code...@gmail.com> wrote: > > Hi Silky > > > > I'm just getting into MVC and C# so please forgive the newbie reply. > > > > The way I have mine setup, the partial view is either in the masterpage > or > > in a view. > > The one in the master page doesn't consume any data, so no issue for me > > there. > > The ones in views, either use the same data that is in the original view > > Model, or I add data to the ViewData. > > No worries, I'm new to it as well, and yeah, that was my #1 scheme. I > actually ended up going with a 3rd option, which was to just load that > data in the partial view itself but by way of an object data source. > It makes the most sense, and was trivial. I'm yet to look into Alans > proposed scheme but it seems promising and may be useful for other > things anyway. > > > > HTH > > > > Cheers > > > > Trevor > > -- > silky > > Every morning when I wake up, I experience an exquisite joy — the joy > of being this signature. > -- Liam McLennan. l...@eclipsewebsolutions.com.au http://www.eclipsewebsolutions.com.au
