ASP.Net MVC控制器注入

Question

I am looking for suggestions on good ways to design a new ASP.NET Mvc project. It is of medium size and is relatively simple in structure. I had initially used Spring.Net to wire my service objects into the correct constructors but now management has told me that Spring.Net or any other IOC container is not to be use in our environment.

I am having a bit of trouble figuring out a good way to set this up without DI. I would like to be able to assign service implementations to controllers in a way that allows for a low amount of coupling between controllers and services and to limit, as much as possible, the dependably of controllers on individual service implementations. I guess my question boils down to that fact that I am unsure of where I should manually wire up my application in the MVC model.

Any suggestions?

Answer 1

Since you are using ASP.NET MVC 3 you could write a custom dependency resolver . You will of course still design your controllers taking interfaces in their constructors in order to weaken the coupling between the layers. And then in the custom dependency resolver, in order to satisfy the ridiculous requirement that was imposed to you, you will have to manually say that when you have an ISomeService you return an instance of SomeServiceImpl . You know, the kind of things that object containers and DI frameworks already do for you. So you will basically have to reinvent some wheels. By the way Ayende blogged about how you could build a custom IoC container in 15 lines of code but of course that's not a reason that you should ever do anything like this.

People imposing such requirements should face a trial and be sentenced to never ever have to approach an application design. Imposing such requirement illustrates some total lack of knowledge about good practices in designing applications. Those people should be advised before they bring further damage to the company.

So simply explain those people that by reinventing wheels there are 2 mistakes:

• you will waste a lot of time for something that was already done by someone else
• you will make errors as you will not take into considerations all the edge cases that were taken into account by someone else designing a reusable DI framework.

At the end of the day you will ship your application late on schedule (as you would have wasted time to write plumbing code) and even worse you will ship an application that will contain potential bugs.

Conclusion: expensive and buggy product. Your management must have really has lost its mind :-)

Conclusion2: use an existing DI framework. Management won't even notice as they don't seem to understand the technical aspects of an application by imposing such requirements.

Answer 2

First of all, I would question why management has mandated that you can't use a pattern and tools that would allow you to achieve loose coupling and dependency injection. Is this something that can be discussed and reasoned about?

With an IoC container, it is trivial to implement an IControllerFactory that resolves controllers from the container and injects the necessary services.

In MVC 3, there is IDependencyResolver which you could use to achieve slightly looser coupling (via a Service Locator pattern/anti-pattern) than instantiating services directly inside controllers; this interface was designed to be used with an IoC container though really and would be a poorer substitute on its own.

Answer 3

Does your boss have pointy hair? http://www.dilbert.com/

You could save yourself some time by using http://unitymvc3.codeplex.com/ rather than writing your own custom dependency resolver. It's downloadable via Nuget http://nuget.org/ . If you use an IOC container such as this, and use constructor injection, you will find your unit tests are much easier to write. That's assuming your manager believes in unit testing ;-) Good luck!

Answer 4

management has told me that Spring.Net or any other IOC container is not to be use in our environment.

Management is telling you that you are not allowed to write loose coupled, testable and higly maintainable applications, that's what they are telling you. That's an odd restriction.

Dependency injection is an advanced technology that many developers don't understand. However, management will never understand it, and it is not their job to understand it. They may dictate the type of technology (.NET vs. Java for instance), because this impacts the kinds of personnel they need to hire, but when they start dictating on low level implementation details that prevent you from writing descent software, your company is heading for disaster.

Leave that company now you can!

Your other option is using the source code of the Simple Injector . The code base is small enough (about 500 lines, just use the SimpleInjector.NET project) to be able to copy it to a local project (and the license permits it). This way it's your own local DI container, but fully tested :-)

Good luck.

Answer 5

You need a new home. There are plenty of organizations looking for talented engineers who care about quality and scalable architectures. Make sure you find the right one and they will be glad to find you.

Avoid the temptation to save your current team from their own short-sightedness. From your descriptions, it sounds like you are already a pariah despite your talents. Accept the fact that you won't be listened to.

The best strategy is to fake being a born-again team player. Build your MVC project exactly the way your boss has asked, ie the dumb way, with no separation of concerns. When version 1 of your project is finish and passes QA (if you have any QA), your boss will probably think he is vindicated. Be prepared for this reaction.

The best hope you have of enlightening your current team members is to show them that even if you build software using the same dumb practices they are comfortable with, you can still run rings around them. This can be fun. Then, when you leave, you give them a chance to reflect on the possibility that you were on to something. They can either take that chance or opt for continued comfort, but it won't be your problem any longer.