Comments on: Displaying [foo] on every page of an ASP.NET MVC application http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/ Thu, 25 Feb 2010 20:23:05 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: ASP.NET MVC views and their data (Where does it come from??) http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-609 ASP.NET MVC views and their data (Where does it come from??) Tue, 24 Feb 2009 11:10:06 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-609 [...] For additional reading check out this, this and this [...] [...] For additional reading check out this, this and this [...]

]]> By: Natalie http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-469 Natalie Fri, 31 Oct 2008 13:28:49 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-469 Graet post mate. Kepp them coming.... Graet post mate. Kepp them coming….

]]> By: Estevez http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-310 Estevez Thu, 14 Aug 2008 07:26:35 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-310 Thanx! Thanx!

]]> By: aaron http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-309 aaron Wed, 13 Aug 2008 12:25:21 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-309 @estevez The RenderAction I spoke of here was custom code available from the link I gave. But it's since been included in the MVC framework (new in Preview 4 I think). You'll have to download and build the source from codeplex (www.codeplex.com/aspnet) to get it, but if you're going to use that functionality I'd recommend using the baked in version. @estevez The RenderAction I spoke of here was custom code available from the link I gave. But it’s since been included in the MVC framework (new in Preview 4 I think). You’ll have to download and build the source from codeplex (www.codeplex.com/aspnet) to get it, but if you’re going to use that functionality I’d recommend using the baked in version.

]]> By: Estevez http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-308 Estevez Wed, 13 Aug 2008 12:22:54 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-308 At 3. solution - what do I have to refer to (set reference to, Import, etc) to use "RenderAction" method? I have RenderControl, RenderChildren, but there is no RenderAction... ... or i just have to upgrade? At 3. solution
- what do I have to refer to (set reference to, Import, etc)
to use “RenderAction” method?

I have RenderControl, RenderChildren, but there is no RenderAction…

… or i just have to upgrade?

]]> By: http-kolman.myopenid.com- http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-307 http-kolman.myopenid.com- Wed, 09 Apr 2008 15:40:01 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-307 If you need to aggregate all the data request calls, as in the case of multitier application, choice 3 is not really suitable - it could end up in a number of small calls to business logic layer. I would prefer all the data-gathering logic to happen before any view is rendered. In classic ASP.NET, this is enabled by the DataSourceControls and the hidden asynchronous nature of DataSourceView's Select method. One of the arguments of this method is callback delegate, that the DataSourceView calls when the data are available. You can write your own DataSourceView that defers actual executing of the data retrieval code to the point that all the DataSourceControls in page (including those in master pages and user controls) have de facto registered their data requests by calling the Select method, and you can aggregate all these requests to a single call over remote boundary. This is enabled by multiphase lifecycle of the Page class and it's controls. Because MVC has no tricky lifecycle (which is cool), it seems like the master page is not the right place to make any additional data requests. In my opinion, that only violates the principle of separation of concerns. So the right approach would be to find some way how to compose the controllers before the view is rendered. Creating a base controller class ("master page controller") could be a solution, but it smells to me a bit as it limits composition. If you need to aggregate all the data request calls, as in the case of multitier application, choice 3 is not really suitable – it could end up in a number of small calls to business logic layer. I would prefer all the data-gathering logic to happen before any view is rendered.

In classic ASP.NET, this is enabled by the DataSourceControls and the hidden asynchronous nature of DataSourceView’s Select method. One of the arguments of this method is callback delegate, that the DataSourceView calls when the data are available. You can write your own DataSourceView that defers actual executing of the data retrieval code to the point that all the DataSourceControls in page (including those in master pages and user controls) have de facto registered their data requests by calling the Select method, and you can aggregate all these requests to a single call over remote boundary. This is enabled by multiphase lifecycle of the Page class and it’s controls.

Because MVC has no tricky lifecycle (which is cool), it seems like the master page is not the right place to make any additional data requests. In my opinion, that only violates the principle of separation of concerns. So the right approach would be to find some way how to compose the controllers before the view is rendered. Creating a base controller class (“master page controller”) could be a solution, but it smells to me a bit as it limits composition.

]]> By: aaron http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-306 aaron Wed, 12 Mar 2008 16:31:57 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-306 Some of this is a little moot with the newest MVC Preview 2 release, but given what I wrote in the post, the easiest to test would be choices 2 and 3. Choice 2 is easy to test because you can write tests for the OnPreAction for each controller (or a base controller). Choice 3 is easy to test because you've effectively "siloed" the functionality into a specific controller/action/view, which you're already testing just like the rest. I'm also not a unit test expert (not by a long shot) so take this with a grain of salt. :) Some of this is a little moot with the newest MVC Preview 2 release, but given what I wrote in the post, the easiest to test would be choices 2 and 3.
Choice 2 is easy to test because you can write tests for the OnPreAction for each controller (or a base controller).
Choice 3 is easy to test because you’ve effectively “siloed” the functionality into a specific controller/action/view, which you’re already testing just like the rest.
I’m also not a unit test expert (not by a long shot) so take this with a grain of salt. :)

]]> By: Bryan Reynolds http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-305 Bryan Reynolds Wed, 12 Mar 2008 16:26:37 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-305 I was glad you took the time to blog about this. The decision here is not an easy one. I am not a unit testing expert yet so I will ask the question. What of the possible solutions above is easiest to test? I was glad you took the time to blog about this. The decision here is not an easy one. I am not a unit testing expert yet so I will ask the question. What of the possible solutions above is easiest to test?

]]> By: Ben Scheirman http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-304 Ben Scheirman Tue, 05 Feb 2008 17:26:53 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-304 Your RenderAction extension method has some of the same concerns as the rails folks did with components. They aren't recommended now due to perf reasons and separation of concerns, and the rails team now favors the use of :before_filter's (OnPreAction). Your last example could use a UserControl instead of the RenderAction, provided the required data already existed in ViewData. Your RenderAction extension method has some of the same concerns as the rails folks did with components. They aren’t recommended now due to perf reasons and separation of concerns, and the rails team now favors the use of :before_filter’s (OnPreAction).

Your last example could use a UserControl instead of the RenderAction, provided the required data already existed in ViewData.

]]> By: Wöchentliche Rundablage: ASP.NET, ASP.NET MVC, System.AddIn, Silverlight, LINQ, C# 3.0, WPF, XBAP… | Code-Inside Blog http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/comment-page-1/#comment-303 Wöchentliche Rundablage: ASP.NET, ASP.NET MVC, System.AddIn, Silverlight, LINQ, C# 3.0, WPF, XBAP… | Code-Inside Blog Mon, 04 Feb 2008 19:11:57 +0000 http://www.aaronlerch.com/blog/2008/01/26/displaying-foo-on-every-page-of-an-aspnet-mvc-application/#comment-303 [...] Displaying [foo] on every page of an ASP.NET MVC application [...] [...] Displaying [foo] on every page of an ASP.NET MVC application [...]

]]>