首先针对ASP.NET MVC和Entity Framework数据库的解决方案设计

Question

我继承了一个ASP.NET（4.6.1）MVC解决方案，该解决方案使用实体框架（首先是数据库）作为其数据访问权限。所有dbcontext调用和所有业务逻辑都在控制器方法中。没有域模型。...仅查看模型和从EF生成的实体模型。

所以解决方案的结构基本上是：

• Web（MVC Web项目）→DAL（EF6 ... class lib proj）
• DAL包含
  • .edmx
  • dbContext-自动生成
  • 实体模型-自动生成
  • 实体模型的局部类
  • 部分dbcontext（包含一些自定义逻辑）
• MVC
  • 控制器
  • 类级别的专用dbcontext
  • 每种方法中一些简单到复杂的CRUD dbcontext调用
  • 模型
  • 仅查看模型（某些模型具有dbcontext调用... oy）
• 观看次数
  • 某些视图使用虚拟机作为其模型，而其他视图使用EF实体模型

至少，我想将我的DAL与我的表示层隔离，并清理我的控制器。我不是要创建完美的应用程序...而是要进行逐步改进。因此，本轮我的目标是创建一个逻辑结构。

因此，我要在Web和DAL之间添加另一个项目（称为Service或其他），并将所有dbcontext调用/逻辑移到该层。我要添加另一个项目（称为Core）来容纳一些DTO，自定义异常和其他东西。

这是我当前的解决方案：

• Web（带有Autofac的MVC Web项目）

  • 某些服务管理器类（注入到控制器中）
  • 这是我获取DTO并将其转换为视图模型或将视图模型转换为DTO以发送到服务层的地方

• 核心（请勿与.NET Core混淆）

  • 所有人引用
  • 实体模型（从DAL移出）
  • 实体模型的局部类（从DAL中移出）
  • DTO，异常等...

• 服务

  • 网络参考
  • 某些服务类（注入到Web服务管理器中）将保留以前在控制器方法（例如：var result = dbcontext.SomeTable where some id = n...blah blah）中的所有复杂CRUD dbcontext调用
  • 我还将DAL dbcontext注入这些类（然后需要引用Entity Framework）

• DAL

  • 服务引用
  • .edmx
  • Dbcontext
  • 部分dbcontext（包含一些自定义逻辑）

因此，我将自动生成的dbcontext保留在DAL中，将生成的实体对象移至Core，以便Service可以看到它们。

我的问题：

1. 将所有dbcontext调用/逻辑移出控制器并移入服务是否有意义？某些逻辑很简单，但是有几种控制器方法也具有复杂的业务逻辑。我只是不确定将该逻辑/调用放在dbcontext的位置。

2. 整体解决方案设计看起来还不错，还是我使其变得复杂了？这是一款中等大小的应用程序，但它具有发展潜力，我想为自己的未来发展做好准备。

感谢阅读...感谢任何输入！