我正在为具有存储库层和服务层的.NET MVC应用程序确定一个相当简单的分层体系结构.我找到了一些相当清晰和简单的例子,特别是www.asp.net,以及这里的一些问题和答案,但我正在寻找一些更简单的东西,适合小型应用程序,但是它使用不同的项目,以获得跨越的想法.我上面链接的示例将存储库和服务作为Models命名空间中的类.这对我来说是不够明确的分离能够恰当地说明它.
我有一个单独的项目用于实现接口IRepository的存储库.Service有一个单独的项目,它实现了IService并获取了一个IRepository(构造函数注入).该服务实现了IService.这个例子就足以让控制器实例化服务,而不需要IoC容器.将其视为理解最佳架构实践的中间步骤,这是逐步构建包含依赖注入和可能更多层的序列的一部分.
问题是,我应该在哪里定义IRepository和IService？当然,服务和存储库项目都需要引用它们.很明显,它们应该在服务和存储库项目引用的另一个项目中定义.如果是这样,那么一个好的命名约定是什么？XXXXContracts之类的东西？
同样,对于在表示层,服务层和存储库层之间传递的数据模型,是否可以使用所有层引用的名为XXXXModels的单独项目？我知道在某些情况下,服务和存储库层之间传递的模型可能与服务层和表示层之间传递的模型不同,但原理是相同的.
我在这里找到了类似问题的答案,但它们往往涉及比我在此概述的更复杂的架构.我希望实现一个非常简单和干净的两层图解,可以看作是参考数据层并在控制器中具有业务逻辑的一两步,这就是全部.我知道有一个强有力的论据可以直接进入全面的最佳实践,但不是每个人都适合一次性完成跳跃.
假设ASP.NET MVC 5和OWIN/Identity成员资格的Web项目.IoC完成了Unity.现在一切都在一个项目内. 问题:将MVC,Idenity和IoC分离到隔离项目并将Identity封装到某些IAccountService中以便Unity在MVC项目中解析是否有意义？ 问题似乎很愚蠢,但我的橡皮鸭保持沉默的原因不明,有什么猜测吗？
我想实现的目标看起来像这样
ASP.NET MVC(OWIN) - > IoC(Unity) - > AccountServiceImpl - > Identity
MVC,IoC - >合同(IAccountService)
其中 - >是项目引用
我需要它能够更改IoC容器,我还需要通过接口从另一个项目访问身份数据