I am about to segregate my MVC3 app into areas, but some controllers and views are common to multiple areas. How can I share these?
I have considered some options here, but would rather take some advice first. I can locate shared controllers/views in the core app, i.e. no in any area, and route and or redirect to actions on these controllers. I can also place controllers in a shared library, and use derived controllers in my areas. Then, similar to my first option, I can use custom controller factories in my areas and use these to target shared controllers in the core app.
How should I go about this?
It really depends on what is common.
Is the HTML common? Then use editor templates or partials and place them in the Shared folders.
Is the controller code common? Then use child actions with the action itself placed in a controller in the root (e.g not in an area).
It's a matter of preference. I'm a big fan of keeping my controllers DRY, so i like use child actions for rendering of common content (think the RHS modules on this page, they would each be a child action for me).
My colleague on the other hand prefers to use abstractions on the view models and duplicate the data access/setup logic in the controllers.
try this.. I think it will help you. http://lostechies.com/erichexter/2009/11/01/asp-net-mvc-portable-areas-via-mvccontrib/
Related
I have a new multi-tenant web application in ASP.NET Core 2.0, single DB.
I've established a method of determining a particular request's 'TenantId' by examining the domain in a simple piece of middleware.
I've also established a DataContext which applies TenantId filters to applicable tables as needed.
The last thing I'm unclear about is how I can differentiate Views/partial views based on the TenantId whilst sharing the controllers.
I think some scheme where the app first looks in some kind of TenantId sub-folder for the customized tenant's view and if it can't find it, it goes through the regular steps to locate the view... might work okay? Is this a reasonable approach? In other words, it should use the specialized tenant view if it exists, otherwise use the default view.
Would this involve building a custom view engine of sorts?
I've tried something similar with tenant based Html fragments, but it was a pain maintaining it, so I'm looking for something more straight forward on this project.
I'm open to other suggestions of how to implement this functionality as well.
Thanks in advance!
You don't need a whole custom viewengine, you can implement an IViewLocationExpander to make it check various locations for views.
In my project I have mutliple tenant support with both shared themes and tenant specific themes. I can override any view by dropping a copy below the theme folder, ie the main view could be Views/SiteAdmin/Index and I can override it in /pathtothemes/themefolder/SiteAdmin/Index
You can see my implementation of IViewLocationExpander here.
How you register your IViewLocationExpander is like this:
services.AddMvc()
.AddRazorOptions(options =>
{
options.ViewLocationExpanders.Add(new cloudscribe.Core.Web.Components.SiteViewLocationExpander());
})
.SetCompatibilityVersion(CompatibilityVersion.Version_2_1)
;
How I can inject an array of services from config.yml giving class names (with namespaces) to a controller? I need to run a function from each of this services in the controller. At the moment I use $this->get('service'); in the controller, but I need to make controller independent from services. Is there a way to do this?
Edit
I don't know names and how many services will be injected, though all of them implement an Interface.
Edit2
Well, probably I did not express correctly my thoughts. I have a bundle named Widgets. It has an array of widget names, display widget holders for each widget and with AJAX I get the content and display it. At the moment I have in the Widget controller hardcoded some widget deffinitions (title and id for Ajax) and some are retrieved by calling getWidgetList from some controllers from another bundle. Well I need that the list of the widgets wont be hardcoded itself in the widget bundle. I need a way to pass this list from the config.yml. Any ideas?
Injecting an array of services is, generally speaking, not the right approach (even if there was a way to do it, which I don't think there is)
The whole reason you don't want to write container-dependent code is to keep your codebase flexible, lithe, and testable. A variable array of services is, in practice, just a mini container, so if you implemented that you'd just be shrinking the scope of the problem, not eliminating it. You'd still be making your code dependent on an arbitrary bucket of services.
I strongly recommend explicitly defining each service your controllers need (as outlined by the links in the comments from Rufinus and Cerad) or look into using something like the jms/di-extra-bundle.
Update
Maybe you need to do more research on the configuration options available?
How to Create Friendly Configuration for a Bundle
The Config Component
http://symfony.com/doc/current/cookbook/bundles/configuration.html
I'm working on a web application. One of my co-workers has written some asp.net forms pages. The page classes all inherit from BasePageClass, which of course inherits from the Page class. I wish to add some MVC controllers that I've been told need to use the same logic implemented in the BasePageClass. Ordinarily, I would want to inherit the functions in the BasePageClass in the controller classes, but this breaks the inheritance hierarchy.
What is the best practice for solving this problem?
If there is common functionality, I would suspect that this functionality should be separated out from the page/controller anyway. This is better OOP/D. Then both your controller base page and your System.Web.UI.Page base can both have properties returning classes that contain this common functionality.
(I've seen a lot of cases where stuff is crammed into the base page that should be elsewhere. Your need for this functionality to be in both the Pages and Controllers is likely just bringing this poor design to light, rather than being a problem in itself.)
Less likely to be what you want, but still a possibility:
You could also put your common functionality in a series of overloaded extension methods, where the first parameter is (a) System.Web.UI.Page and on the other overload (b) System.Web.Mvc.Controller.
Both your base page and base controller could implement a common interface, wrapping functionality stored in a common place.
Pull this functionality out altogether and do it as needed in your controler-logic and code-behinds.
I am designing a web application that requires loading multiple components on a single page. (In terms of page layout is similar to Google reader) I like to keep these components separate from each other (for reasons such as reusability). For example, I have a left panel that let's user navigate among multiple feeds that he's subscribed to (user specific) and on the right side of that we show the contents of that feed, and maybe a right panel which shows some specific info about that specific feed.
My understanding of MVC and more specifically Spring-MVC is that each controller is in charge of the entire page. Here are 2 solutions that I have came up with after researching this a bit, and none of them sounds good to me.
Have a main controller that is mapped to that URL, and then load the other components from inside the jsp file. This is doable but doesn't sound like a good solution.
Using portlets.
I want to know what are the best practices. This sounds like a very common web design issue in MVC frameworks, how do people do it?
Spring MVC controller is usually "in charge" :-) of handling a particular request which does not necessarily mean that said request results in a monolithic page being presented to user.
Since you're talking about Google Reader-like functionality, perhaps you'll be using AJAX to load / navigate between different components on your page? If that's the case, you can easily map your 3 components to separate controllers (via separate URIs) plus have one "main" controller to initially load the entire page.
If that's not the case and your page is static, you can have your controller act as "router" of sorts by first instantiating your components and then directing commands / requests to an appropriate component as necessary. Each component would update its own part of the model after which your "main" controller would return the view to be rendered.
Can you use portlets for this? Sure. But if we're talking about a single page it might be a tad overkill.
This may be a broad question because part of the problem is that I actually don’t know what the question is. What I would like to know is how you commonly organise ASP.NET applications in terms of placement of pages (aspx), user controls (ascx), server controls and other support classes and utility functions etc. First, let’s assume that there is already some data layer somewhere (perhaps in a different project). This is the not issue.
The issue I frequently face is that create several pages and realize that they need to share some common rendering logic or some utility function, class etc. Another typical case is that some pages become too large so that it seems handy to split them (say into some user controls). What is the best place to put these utility classes, share classes, user controls, server control etc.? Here are several possibilities.
Don’t really care about any organisation and place all types of files next to each other. So in one directory, you may have an aspx files, some cs files etc. This is not really an option probably.
Organize files by types. Let’s say you create a directory for user controls and put all user controls there. OK, but what about server controls and other regular classes? Should they be in special directories as well? It does not sound right. What I dislike most on this is that when you work on a feature (logically related piece of code), you must hunt it all over the place. I think that features and logical sections of your applications should be also grouped on the file system level in some way.
What I would like to have is to have the pages (aspx), user controls (ascx) and handlers (ashx) basically as dummy placeholders sitting in the directory structure organized from the logically according to the point of view of the outside visitor while the actual code (page, user controls implementations, serve control and utility classes) should be placed in s different folder structured into logical namespaces (organized by the modules or features of the application). It seems to me that the only way to achieve this is to manipulate the <%# Page ... %> directive manually.
Does it sound crazy? Am I asking too much? Is there a better way? What are your best practices? Do you know some good examples?
Edit: Another idea. This does not mess up with the generated aspx, aspx.cs and aspx.designer.cs files. One on my original requirements was that I wanted to place the code driving aspx pages to my own location and put it to a custom namespace hierarchy. So what if I simply subclass the aspx classes generated by VS? Let’s say I have a project called MyApp and MyPage.aspx page in it. VS then creates MyApp.MyPage inherited from System.Web.UI.Page. I leave this class be (no code will go there), but create a subclass, say in MyApp.SomeNamespace.SomeSubNamespace.MyPage, inherited from MyApp.MyPage. This way MyApp.SomeNamespace.SomeSubNamespace.MyPage will get access to the autogenerated protected fields corresponding to the server controls of MyApp.MyPage and I’ll get an entire "private" namespace for all the support classes which are related to this page. Any major disadvantages? Another related problem which bothers me is where should this new cs file be physically placed? In web projects, there is a standard folder for it called App_Code, but I’m interested in web applications. Creating a directory in the root of the application (such as Code) does not sound right.
Remember that you can create page classes that don't actually correspond to any markup. We often create base pages that our actual UI pages inherit from. This is a simple way of organizing "base" page functionality. Then when you create your .aspx pages, make them inherit from the base page class, rather than System.Web.UI.Page.
We usually place our base page .cs files into the top level directory if it's a small project, or for slightly larger projects we'll create a "Shared" or similar directory where they live.
However, we also have a huge enterprise web project, and we simply build our webcontrols and base pages into a class library called CompanyName.Web.UI, with a couple sub-namespaces to that. All our actual web site projects import that assembly and all the code for the controls, etc. is elsewhere. This sounds like it might be a good option for you.
If you remember that your .aspx codebehinds can inherit from any class file, it should make it easier for you to organize.