将Business Logic类放在实体框架中的位置 - ASP.NET MVC 4解决方案？

Question

我有一个解决方案，其中一个项目是Entity Framework并且有我的ASP MVC项目，我在POCO对象和DBContext（带有静态类的业务逻辑层）中寻找创建想法的一些建议或意见拥有所有方法（例如带有GetContactByID，GetAllContacts，GetContactsByType的ContactBLL类），以允许访问模型数据，并且可以在Controllers Actions中访问。通过这种方式，我不必将此方法的实现代码放在Controller Actions方法中，并且可以在其他Action Controller中调用此方法重用它。我将非常感谢您的意见，因为它可以指导我回答一个问题，我已经在一周左右的问题中回答了这个问题（关于在哪里定义DBContext以及如何使用它）。

Answer 1

您可以根据核心功能创建不同的项目。

1. 您可以制作Project.DataAccess的数据访问层（数据库上下文和存储库等），它只有db上下文类和存储库。

2. 业务逻辑层（Project.Business）它将具有业务逻辑并调用数据访问层。

3. UI Layer（Project.WebUi）它是mvc项目。 等等。

有关详细信息，您可以看到此http://prodinner.codeplex.com/代码

Answer 2

1. 为您的POCO创建单独的类库，

2. 然后为您的存储库创建另一个类库，这应该是 仅包含存储库所需的接口

3. 并且实现将在另一个类lib上，如Project.EF， Project.NH将包括实体映射，迁移，存储库 实现。但实际上，你很可能不会改变 你的ORM lib一旦实现，因为它只会导致你 很多头痛（只是我的2点）。

4. 您将创建业务层（类lib）和

5. web项目作为单独的lib。 MVC项目的Models文件夹将包含您的ViewModel。

这就是我现在使用的，当然不是最好的结构，它只是我满意的东西:)。希望能帮助到你。

Answer 3

通常，ASP.NET MVC中有四个标准项目 - 实体框架解决方案。它们是1）MVC，2）核心/业务逻辑层（BLL），3）数据访问层/ DBContext（DAL）和4）公共/实用。

1. 标准MVC项目包括三个主要元素，分别是模型，视图和控制器。但是，中间到复杂的解决方案通常会从MVC项目中切断Model元素并将其移回BLL，我们将其称为ViewModel（POCO）。遵循这种结构，MVC项目现在负责雇用/使用BLL的服务并通过控制器控制UI。

2. 业务逻辑层（BLL）是实现业务逻辑的核心。它负责提供来自MVC项目的请求，并与DAL一起工作以持久保存数据。如上所述，BLL是定义ViewModel的地方，它的关系以及接口/抽象类支持实现设计模式。 Viewmodel（POCO）很可能在DAL中将一对一映射到数据实体，但我们不直接在View上使用数据实体。遵循此结构将有助于增加ViewModel的自定义，如添加约束

3. DAL是DBContext及其数据实体的所在地。

4. 公共项目包括Logging等共享功能，用于1）2）和3）

请阅读更多内容 https://www.codeproject.com/Articles/70061/Architecture-Guide-ASP-NET-MVC-Framework-N-tier-En https://chsakell.com/2015/02/15/asp-net-mvc-solution-architecture-best-practices/