带有服务层和存储库层的ASP.NET MVC,应该在哪里定义接口？

Question

我正在为具有存储库层和服务层的.NET MVC应用程序确定一个相当简单的分层体系结构.我找到了一些相当清晰和简单的例子,特别是www.asp.net,以及这里的一些问题和答案,但我正在寻找一些更简单的东西,适合小型应用程序,但是它使用不同的项目,以获得跨越的想法.我上面链接的示例将存储库和服务作为Models命名空间中的类.这对我来说是不够明确的分离能够恰当地说明它.

我有一个单独的项目用于实现接口IRepository的存储库.Service有一个单独的项目,它实现了IService并获取了一个IRepository(构造函数注入).该服务实现了IService.这个例子就足以让控制器实例化服务,而不需要IoC容器.将其视为理解最佳架构实践的中间步骤,这是逐步构建包含依赖注入和可能更多层的序列的一部分.

问题是,我应该在哪里定义IRepository和IService？当然,服务和存储库项目都需要引用它们.很明显,它们应该在服务和存储库项目引用的另一个项目中定义.如果是这样,那么一个好的命名约定是什么？XXXXContracts之类的东西？

同样,对于在表示层,服务层和存储库层之间传递的数据模型,是否可以使用所有层引用的名为XXXXModels的单独项目？我知道在某些情况下,服务和存储库层之间传递的模型可能与服务层和表示层之间传递的模型不同,但原理是相同的.

我在这里找到了类似问题的答案,但它们往往涉及比我在此概述的更复杂的架构.我希望实现一个非常简单和干净的两层图解,可以看作是参考数据层并在控制器中具有业务逻辑的一两步,这就是全部.我知道有一个强有力的论据可以直接进入全面的最佳实践,但不是每个人都适合一次性完成跳跃.

Answer 1

介绍

这也是我自己也问过的.我一直有的一个问题与你的问题相似;

一个好的命名惯例是什么？

我应该如何命名？他们应该进入文件夹或项目吗？

在搜索之后我怀疑答案是它并不重要.重要的是,您的解决方案具有一些合理的架构,并且您尝试遵循SOLID等良好实践.

我关于这个主题的ASP.NET MVC英雄是Jeffrey Palermo,Steve Smith和Jimmy Bogard.

洋葱建筑

杰弗里·巴勒莫(Jeffrey Palermo)讨论了旧观念的组合,但将它们结合在一起并赋予其洋葱建筑的视觉刺激名称(推荐读物).杰弗里展示了一个解决问题的好方法.他解释说,在你的应用程序的中心(或顶部)你有你的核心.这个层是你应该放置IRepository和等接口的地方IService.

几乎所有的接口都应该进入核心,其他所有(其他项目)都可以引用核心.这样一切都知道应用程序的骨架结构,而不知道实现细节.

尝试尽可能少地(在合理范围内)使用您的UI图层引用.在我的一个应用程序中,我的UI(MVC)层仅引用Core.它所需要的一切都通过依赖注入注入其中.

史蒂夫史密斯通过MVC解决方案最佳实践中的演示讨论了洋葱架构和类似的想法:解决方案问题的解决方案

我的解决方案

在我的MVC解决方案中,我有一个典型的结构,如下所示:

• MyProject.Core
• MyProject.Domain
• MyProject.DependencyInjection
• MyProject.Infrastructure
• MyProject.Web
• MyProject.Tests

该核心包含我的接口.它通常分为服务,模型,域,存储库等文件夹.

该域名层仅参考核心,包含我的实现.它为核心中的域抽象提供了许多具体的类.它涉及许多业务逻辑,处理,命令处理,管理器类,具体服务实现等.我认为它是一个相当内层,因此它尽可能少地引用.

该DependencyInjection层包含我的选择DI包/框架和实施细则.我认为它是一个外层; 类似于UI或基础设施,所以如果它引用很多就没关系.这个图层不一定是一个单独的项目,许多人会告诉你不要这样做.没关系; 做什么适用于您的项目的复杂性.我喜欢我的DI是自己的东西.关于它如此独立的好处是我可以用不同的方式替换DI框架,事情就好了.没有图层参考DI项目.

在基础设施层包含有关记录,电子邮件和数据存取信息.它将包含我选择的ORM.这不是商业逻辑的东西,也不是UI的东西.这是我完成任务的解决方案的铁路.它位于外层,但它仅引用Core.

该网络层是我的MVC项目,只引用核心.

复杂性和最终的想法

我在这里找到了类似问题的答案,但它们往往涉及比我在此概述的更复杂的架构

这是一个好点.记住问题的复杂性非常重要.但不要被良好的解决方案做法所吓倒.我的解决方案和洋葱架构不一定非常复杂,并没有真正膨胀你的解决方案.他们只是把事情分开.

在进化项目结构中,吉米博加德谈论的事情过于复杂.如果我所说的看起来太复杂,请按照Jimmy的建议将其全部放在一个项目(您的UI层)中.没关系 - 只要它适合你.

记住只把我的解决方案作为一个想法 - 需要考虑的事情; 我的方法是尝试从最好的方面遵循圣人的建议,但我确信我只是取得了如此多的成功; 我可以(并且必须)仍在改进.