关于MVC使用Unity、StructMap做注入，有什么好处呢？
看到有些人写的实例，控制器构造函数中带有N个接口参数。

为什么这样？这样就是省了个实例对象。和我new出来有什么区别？
------解决方案--------------------
程序员眼光增加劳动量，架构师眼光解耦。
------解决方案--------------------
程序员眼光增加劳动量，架构师眼光解耦。
+1
如果你一定需要一个好处来合理化被加大的工作量
那么我就给你一个~
Ninject：
ninjectKernel.Bind<ICategoryService>().To<CategoryService>().InRequestScope();
Autofac：
builder.RegisterType<CategoryService>().As<ICategoryService>().InstancePerHttpRequest();

基本上所有IOC都类似的功能，那就是在一个http请求中，只实例化对象一次，并且在请求后释放
比如在一个查询分类，和查询产品的页面中，按传统的方式，你要实例化数sqlconn或EF两次
有了IOC，只要实例化一次就好（减少了内存和垃圾回收，第二次使用是用第一次的，所以也快了），而且他们不是单例模式，http请求完毕，就释放了，这是new方式做不到的~

IOC除了解耦外，还提供了新的控制对象声明周期方式
------解决方案--------------------
方便软件的组合——在不修改和重新编译源代码的情况下，仅仅通过配置文件和拷贝程序集dll文件实现不同的功能。
------解决方案--------------------

引用:

一个小小网站就用到这种高尚的竟淫了？

有必要才用，有些时候盲目地模仿是多余的
------解决方案--------------------

引用:

这样倒是好。但我见的那个是把数据层做为CONTROLLER的构造函数参数传入，这样的优点怎么说呢？

依赖注入有2种方式
构造函数注入和属性注入
但因为属性注入需要引用IOC的命名空间和在属性上添加特性，所以一般都是选择构造函数注入
没有什么好处的，必须这么做，
其实还有另外一种，就是从容器中取出来
public static class IocService
    {
        public static T Get<T>()
        {
            return DependencyResolver.Current.GetService<T>();
        }
    }
在公共帮助静态类中，不能使用构造函数和属性注入，因为他们都是静态的，永不释放，那么就可以使用这种方式
IocService.Get<ICategoryService>().xxxFunction(arg...)

我用Autofac的原因是因为属性注入不需要引用IOC的命名空间和在属性上添加特性 呵呵~

------解决方案--------------------
构造方法本身就隐含了强制性，如果你不提供参数就没办法实例化
------解决方案--------------------
其实就是反射
------解决方案--------------------
反射也是要时间的 自己直接写省点时间，记得垃圾回收就行了。总的来说，反射是实现软件工程的一种管理方式。