Question

我目前使用以下架构，只有3层：

*TestProj.Api
*TestProj.Core
     -Models
           Customer.cs
     -Services
          CustomerService.cs
     -Interfaces
          -Repositories
               ICustomerRepository.cs
          -Services
               ICustomerService.cs    
*TestProj.Data
      CustomerRepository.cs
      BaseRepository.cs

我认为将Domain Models和每个接口放在Core项目中是一件好事。我还想到了为什么不将包含所有业务逻辑的服务放在Core中，因为业务逻辑在技术上是域的一部分，如果不采用贫乏的域模型方法，甚至可以在域模型内部。

我对这种架构非常满意，但是我想知道我是否可以从摆脱核心和创建项目中获益：TestProj.Services和TestProj.Domain并将接口放在与其实际类相同的项目中（例如：ICustomerRepository现在位于带有CustomerRepository的TestProj.Data中，而ICustomerService现在位于带有CustomerService的TestProj.Services中。

Answer 1

有趣的问题。假设您的域模型和数据模型是相同的对象。首先，我可以先提出以下设置

TestProj.Api
TestProj.Domain.Models
      -Customer.cs

TestProj.Domain.Services
      -ICustomerService.cs

TestProj.Domain.Services.Implementations
      -CustomerSerice.cs (implements, IcustomerService, Depends on ICustomerRepository)

TestProj.Data
     -ICustomerRepository.cs
     -BaseRepository.cs

TestProj.Data.EntityFramework
    -EfCustomerRepository.cs(Implements ICustomerRepository)

TestProj.Data.UsingSomeOtherORM
   -OtherOrmCustomerRepository.cs(Implements ICustomerRepository)

随后的原则是

每个项目都可以引用Domain.Models，但Domain.Data不引用其他项目（以瞄准）
将合同（接口）与实施分开。
应该能够改变实施/ 反转依赖

For -

我想知道我是否可以摆脱核心和创建项目

您获得的主要功能是依赖性反转以及将解决方案分解为非常小/可独立测试的项目的方法。如果需要，还可以为您的业务逻辑（服务）和数据层提供不同的实现。

希望这有帮助！

将域模型，BAL和接口拆分为单独的项目的好处，而不仅仅是合并到一个名为Core的项目中

1 个答案: