IoC 是不是会导致 ASP.NET MVC Controller 构造函数的参数过多？

Posted 2023-03-31

【中文标题】IoC 是不是会导致 ASP.NET MVC Controller 构造函数的参数过多？

【英文标题】：Will IoC lead to too many params for ASP.NET MVC Controller constructor?IoC 是否会导致 ASP.NET MVC Controller 构造函数的参数过多？

【发布时间】：2009-05-16 14:10:09

【问题描述】：

我决定将 ASP.NET MVC 用于网站项目，并希望遵循所写的一些最佳实践。

因此，我将域/模型分离到一个单独的项目中，创建了 IRepositories 和具体存储库，现在我将注意力转向了 Castle Windsor 作为 IoC。

我现在面临的问题是，对于特定的 Controller，我现在必须在构造函数上传入多个 IRepository 参数。

我的问题是：

我是否可能创建了太多存储库 - 通常，我将 1 个存储库映射到 1 个实体类到 1 个数据库表。我的存储库是否应该有效地包含多个实体/数据库表？ 我是否错过了 IoC 和依赖注入的要点，我是否应该不关心参数如何传递到控制器构造函数中？

给出某种上下文。该网站的一部分将显示可按物业类型（城堡、房屋、酒吧等）、位置（邮政编码、城市）、搜索的物业谷歌地图开放时间等 因此，这些可搜索组件都是独立的实体 PropertyType、Address.City、Address.Postcode.Lat+Long、OpeningTime.DateTime。因此，还有 3 个单独的存储库必须传递到 SearchController 构造函数中。

这是一个简单的示例，但我可以设想未来将有更多存储库参数传递到其他控制器。

希望这一切都有意义。

感谢您的任何回答或建议。

【参考方案1】：

我不会关心你传递给构造函数的参数有多少，IoC 将处理其中的所有逻辑。

如果您的控制器最终包含太多参数，我会考虑分解控制器的功能，或者将逻辑移动到服务类中。

至于存储库，我通常使用通用存储库，它在实现中采用单个实体。然后我有一个服务类，将这些信息聚合到逻辑单元中。在这种情况下，您的控制器只需要访问服务。例如：

interface IRepository<T>

    IQueryable<T> GetAll();
    T GetOne(int id);
    void Save(T item);
    void Delete(T item);


class OrderService

    public OrderService(IReopository<Order> orderRepository, IRepository<OrderDetail> orderDetailRepository, IRepository<Payment> paymentRepository, etc)  

    public Order CreateOrder(List<OrderDetails> details)
    
    // .. other aggregate methods

【讨论】：

感谢您的回答。 2 请继续提问：1）当你说不关心控制器构造函数的参数数量时 - 我仍然必须实际编写构造函数，但是是的？ IoC 不会在幕后实际为构造函数创建代码吧？ 2）想必，由于Service类只包含接口，那么将它作为类而不是接口（IOrderService）传递给Controller是可以的，并且仍然允许分离关注点并允许轻松测试？再次感谢

1) 是的，您仍然需要设置完全加载的构造函数。 2）您的容器将处理加载接口时要使用的类实例。看到这个最近的问题，我写了两个可能有帮助的答案。 ***.com/questions/871405/…