Been lurking for a few months and decided to jump in with a question. I am very new to Windsor and IoC in general. I can get Windsor to work with my MVC2 project with no problem. The project I am working on is a "portal" of multiple applications under one MVC2 project using the new Areas concept. In this scenario, each Area will actually be a separate application inside the "portal". We are doing this to effectively share a LOT of common code, views, authentication, and cross-application functionality. Many of our apps link to one another, so it made sense after discussing it to combine them into one project.
What I am wondering how to do is actually allow different Areas to inject different concrete classes? In my limited understanding, the Application_Start is governing building the container and assigning it as the controller factory. I don't necessarily want to do all the injection at the application level. We have a config system where we have a config.xml at the root of every Area and those settings override any root settings. I would like to continue that trend by having the injections for each Area be read by the Area's config.xml (an inheritance similar to Webforms web.config where the config in a lower folder overrides settings in a parent folder).
Example: I would have an ILogHandler which would need a different concrete implementation depending on which Area of the application I am in. So I would need to inject something different depending on where I am at in the application.
I can easily do this using factories since each area could have it's own set of factories, but I am attempting to take this opportunity to learn about IoC and what the benefits/drawbacks are. Any help would be appreciated.
Just FYI - you absolutely must not have area-specific security code. For example, a factory or invoker which injects [Authorize] attributes depending on the current area could open your application to attack.
Contrast this with a MyAreaBaseController, which all controllers in your area must subclass. [Authorize] attributes (and other security-related code) here are OK since they're applied to the type and are independent of any concept of "area".
Related
I am looking to add multi-tenancy to an .net core MVC application i am developing.
My aim is to have a core project which contains the base features, including controllers, views, assets etc.
Then I would like to have a separate project per tenant which can override the defaults from the core project. At the moment i am trying to tackle the task of overriding controllers, not just at the controller level but the ability to override individual actions within a controller.
What are should i be looking to to do this, I was thinking about the IControllerFactory but not sure if this is the correct place in .net core?
I'm assuming there may be a away to achieve this with IoC but need pointing in the right direction.
Anyone have any thoughts on this?
This is the way I designed it on my current project, my requirement is slightly different to yours in that its multi-tenated but a tenant can operate in mutiple countries, the functionality is the same per tenant but different per country, the design below will hopefully give you a few ideas to help you on your way.
I treat the controllers as nothing more than a navigation mechanism, keep them thin and light. I have an area per country (in your scenario this could be an area per tenant)
Each areas controllers simply reference a base controller
The base controller is very light because we want be able to implement custom logic per country using our DI container. Lets run through the Edit scenario for a permit.
Intellisense playing up view shouldnt be red :)
Edit permit calls _editPermitManager which is of type IEditPermitManager injected into our controller. I have two implementations of this in the system one for New Zealand because its a special case and one all other countries use (but you could easily have an implementation per country).
I manage this injection with ninject
The flow is user navigates to /blah/NewZealand/Permit/Edit/4 clicks submit this is directed to Permit controller in NewZealand therefore ninjects injects the New Zealand edit manager and this is invoked on the edit flow, I also inject in a INavigationService (_navigationService.Route) enabling me to potentially direct to different views on a per country basis.
Hopefully that gives you a starting point.
I am currently setting up a simple MVC application that is structured as an Onion Architecture. For simplicity's sake, assume that I have the following projects (disregarding the business and database layers, at the moment):
Sample.Web - This is the ASP.NET MVC Application
Sample.Application - This contains the application services.
Sample.Infrastructure - This contains the infrastructure services.
For now, I am using Ninject (although that will likely change). So, with Ninject MVC, I am registering the Application and Infrastructure services at startup, using the Sample.Web to act as the composition root. Application services from Sample.Application are injected into the controllers, and that is straightforward enough and working well.
Where I am having issues, though, is determining how to properly initialize MassTransit, in the equation. Ideally, I want to have a generic interface to wrap the ConsumeContext instance and allow for me to set up the events. I do not seem to be able to fully set up the instance from within Sample.Infrastructure, as the infrastructure does not/should not know what the events are. I would assume that the consumer classes should exist in Sample.Application, and I do not think that the infrastructure should have a dependency on knowing the consumers.
On startup, System.Web will load the NinjectModule from each System.Application and System.Infrastructure. Does that mean that System.Web should have explicit knowledge of the consumer classes, so that it can configure the IBusControl instance, or is there a more elegant solution?
Right now, the path that I think I am going down is that Sample.Web will load the NinjectModule instances, as it does, and then I will configure the ConsumeContext from Application_Start, after I have explicitly loaded the consumers. However, that would mean that I would have to rebuild/redeploy Sample.Web if I ever add consumers, which is less than ideal and is the root of my concerns. Assuming that consumers are defined within Sample.Application, and all event publications and subscriptions exist within Sample.Application, having to touch either Sample.Web or Sample.Infrastructure to add a consumer is code smell.
Many thanks, in advance.
Edit
As always, after hitting submit, something else comes to mind. I think that one possible solution may be to have Sample.Web as Sample.Application for the known endpoints. Since all events will be published and subscribed from Sample.Application, it would make some sense to have Sample.Web create the actual instance in Sample.Infrastructure and compose the endpoints from what it learns from Sample.Application.
Am definitely open to other solutions, though.
I have an MVC solution setup like this, with three 'projects'.
Web (MVC Project, Views, Controllers, ViewModels)
Models (Domain Objects)
Persistence (nHibernate Mapping, SessionFactory)
I need to begin building the repositories, and was going to start with the Authentication Model. Basically following the default MVC template, have an IMembershipService and an IFormsAuthenticationService and related classes (using custom code, not built in authentication providers).
My question is ...where should this go? My Repositories will need access to both my Domain objects and my Persistence Layer. However I keep reading that any kind of 'coupling' means it is a bad design. So I am hesitant to create a fourth project for the Repositories/Services that references the Models/Persistence ...but I can't really find any other way to do it logically.
This is very subjective.
Do what makes sense to you and your team.
I throw them in with the rest of my Repositories. I mean a User is pretty central to any application right? Does a User own anything? If so then isn't he an root?
Repositories are part of the domain.
Tension will always exist between reducing assembly references and minimizing number of projects. That is, you can make each assembly reference fewer dependencies by breaking up functionality into more fine-grained assemblies; however, excessive division of a project into many assemblies requires more effort to manage.
Another point worth mentioning is that authentication has a couple sides to it. One is managing the model around Users, Roles, Permissions, etc. - this is a domain concern. The other is interfacing with the context of execution (whether this is an ASP.Net app, WinForms, etc.) - this is an infrastructure concern. Consequently, I end up with a small service in my MVC project or WinForms project that performs functions like setting Forms Authentication cookies, or setting the current thread principal, etc.
The Separated interface pattern says that your models and repository interfaces should be in a seperate assembly, apart from the GUI and the actual repository implementation. This is to be able to switch implementations later on and to be able to simplify testing.
I would have no problem with putting the interfaces along with the repository interfaces and the actual implementation in the mvc project or the repository project. It's quite easy to move stuff later on if you use a IoC container.
I've been puzzled by what I consider a contradiction in terms: ASP.NET MVC claims to be furthering and supporting the "separation of concern" motto, which I find a great idea.
However, it seems there's no way of separating out controllers, model or views into their own assembly, or separating areas into assemblies.
With the fixed Controller, Model and View folders in your ASP.NET MVC, you're actually creating a huge hodge podge of things. Is that the separation of concerns, really?? Seems like quite the contrary to me.
So what I'm wondering:
how can I create an ASP.NET MVC solution that will either separate out controllers, the model, and the folders full of views, into separate assemblies?
how can I put areas of ASP.NET MVC 2 into separate assemblies?
or how else do you manage a large ASP.NET MVC app - which has several dozen or even over a hundred controllers, lots of model and viewmodel classes, and several hundred views?
I think you're looking for Areas in ASP.Net MVC 2. There are some things to uncomment in the CSProj files, but after that it will copy the views over when you build. I don't think there is any requirement that the Controller or Model classes be in the same assembly as the views.
Walkthrough: Creating an ASP.NET MVC Areas Application Using Multiple Projects
Controllers: AFAIK you shouldn't have to do anything special to throw controllers into their own assembly. At the very most all you'd have to do is override the GetControllerType method of your ControllerFactory.
Models: Zero restrictions on where you put your models. Although this is frowned upon I regularly use persistent objects from an Nhibernate/other ORM layer or WCF/service layer DTO thats are located in a separate assembly as my views. This works the same way using WebForms.
Views: Views in a separate assembly must be marked as embedded resource and then you must use a custom VirtualPathProvider that knows how to get the views from an resource instead of the file system. views from an resource instead of the file system. Again this is the exact same technique you would use for WebForm development.
Regarding mcintyre321 and his Portable Areas answer: The linked project does barely anything custom and simply wraps up the existing MVC 2 extensibility points into an easier to use abstraction. Its barely "custom" and more syntactic sugar.
You manage a large MVC app just like you'd manage any other large app. I dread opening up a 500 page WebForms project because you never quite know whats in each of those code behinds. With MVC distinct functionality is mostly within its right place. Its not contrary at all.
Separating code into separate assemblies is orthogonal to separation of concerns. Where the code lives is not a "concern". Separation of concerns has to do with responsibilities and direction of dependencies of various components. For example, Views are responsible for rendering the output, and the controller knows about the views, but the views don't really have intimate knowledge of the controller.
Likewile, Models don't know anything about either views or controllers, but both views and controllers will know about the model.
However, back to your question. As jfar points out, moving controllers and models into another assembly is trivially easy and will work. Moving views into another assembly is trickier. Embedded resources with a custom virtual path provider is one way, but not one we generally recommend for a high performance site. But if it meets your needs, go for it.
MVC is very extensible and does not require to adhere to the Controller, View, and Model folder structure. You can place the controllers anywhere you would like, however if they are located in another assembly you will need to implement your own controller factory that knows how to locate them. Here is an example for locating your controllers with Windsor.
Your models/view models can be where ever you want. You simply need to reference their namespace in the web.config so views know where to look. (At least I know this is true with the Spark view engine.)
You put your views in any web project. My usual strategy is to create a plain web (non-mvc) project that contains the views folder. (This could even be a legacy web app!) Then all my controllers go in a separate class library. My view models and services go in another.
As far as structuring folders, I usually center my hierarchy around domain concepts. I'd have a folder in each project for Users, Products, Orders, etc. I never have a Models or Controllers folder anywhere.
You need to use portable areas see http://www.lostechies.com/blogs/hex/archive/2009/11/02/asp-net-mvc-portable-areas-part-2.aspx
We will be developing a very large vertical market web application, and are leaning toward the MVC approach.
It will have 1 Master Page common to all views in the application.
The master will provide a navigation/search framework for the entire application
that will allow users to search and select entities and then navigate to a function to perform.
The database model will have 700 to 1000 tables.
The application will have hundreds of controllers.
Controllers and their views could be grouped together into one of the many (20-50) subsystems in the application.
(We are looking at an areas approach to aide in organization).
We want to be able to deliver enhancements/updates in small functional pieces.
These might me a new function, a bug fix, customer dependent functionality, or optional modules separately purchased by the enduser.
We spent too many years developing/supporting and delivering one large windows vb app exe.
We would like to take another approach.
Management does not want to deliver one large application. They want to be able to deliver
small incremental pieces when necessary.
We may want to create a deliverable that contains one controller, and only a couple views, and a portion of the model.
To deliver it, we want to copy a dll to a bin folder, and create a View folder and copy in the new view(s). As simple as possible!
I have spent many days researching this and haven't come up with a clear path to proceed.
(Every tutorial and article I found assumed a single project.)
How do we structure the application to accomplish this?
How do we break up the application into separate projects/assemblies to do this?
Can you build a base project that contains the Master Page, authentication, and Global routing,
and then reference this in each of the potentially hundreds of other projects for each of the modules?
In development, does each sub-project need to contain the entire base project, or just the shared views folder, Global routing,
and web.config and a reference to the base project dll?
Any detail documents explaining this approach?
Any development/Testing issues?
Thanks for all input, we have to get this going soon.
Update:
Followed the example here link text
It is a great starting point!
I think this is exactly the case where DLR would help. Your Controllers and Views can be stored as scripts in the database. It will be very easy to deliver your application as a set of "small functional pieces". You could start from reading Haacked - Scripting ASP.NET MVC Views Stored In The Database
Absolutely, break the project up into sub-projects / modules containing your controllers. You can use an IoC container like Unity, Spring.Net, or Castle Windsor to locate your appropriate controllers in the child projects.
Implement your own IControllerFactory to do the Controller lookups in the IoC container based on the controller name passed to it. You're looking to put in place an IControllerFactory.CreateController method that looks something like:
public IController CreateController(RequestContext requestContext, string controllerName)
{
return (IController)IoCContainer.GetObjectByName(controllerName);
}
Then you should be able to simply modify your IoC configuration file to define your new controllers as they are deployed.
Google for MVC with MEF. There is an example by one of the MEF team that will suit your needs exactly.