Question

我已经阅读了很多文章，它们似乎因作者/开发者而异。在我的情况下，我正在考虑测试项目的这个设置：

通过ASP.NET MVC的表示层
服务层（我的计划是ASP.NET MVC Web API;这是单独的程序集）
业务逻辑层
使用EF进行DAL

有些文章说我不应该把CRUD操作放在BLL上，而BLL应该只包含业务逻辑。另外，有些人说BLL不应该访问DAL。但是，如果业务逻辑需要存储在DB中的数据来计算/处理逻辑呢？我想我的问题是：

如果BLL不应该访问DAL，那么需要DB中的数据以便能够执行逻辑的那些业务逻辑呢？
BLL是实体，对吧？它们是否与POCO相同，或者我还会在DAL中使用POCO吗？
另外，BLL中的DBContext是什么？有人说它应该让我感到困惑。
BLL中没有CRUD怎么样？我应该这样做吗？
存储库界面在DAL中？

有关我计划的设置非常受欢迎的任何其他意见/建议/信息（即使它与BLL无关）。

Answer 1

我不久前在一个项目上工作过。

我们的项目建筑重新符合您的建议。

我们有一个ASP.NET MVC站点，它访问了一个WEB API（在外部解决方案中）。

WEB API还引用了一个完全由静态库组成的外部解决方案，其中包含数据层（只是实体）和持久层。

我们还有 数据传输对象 （MSDN），用于Web服务和客户端之间的通信，并将实体完全与外部解决方案分离。

我们在WEB API项目中有业务逻辑。我们将在WEB API HTTP方法中创建，操作和存储实体。

但我们没有直接访问数据和持久层，我们有一个中间层，我们称之为实体管理器。这些管理器将被注入我们的WEB API控制器（我们使用Ninject进行依赖注入）并将处理实体的创建以及持久性，因此我们将所有内容分离。

这种方法对我们来说非常有效，我们制作了一个非常易于维护和可扩展的项目。

我希望它对您有所帮助，当然，可能存在更好的技术。

<强> PS：

我们使用了entites经理提供给我们的IRepository接口来持久保存实体。这是我们对持久层的唯一访问权限。内部逻辑，例如持久性策略（如EF的DbContext或File IO）将是持久性项目的内部。

这是我们的一个WEB API HTTP方法中的业务逻辑示例：

// "repository" is an IRepository<Entity>
entityManager.Transaction( (repository) => {
     Entity ourEntity = repository.CreateNew();

     //Manipulate the entity somehow

     repository.Add(ourEntity);
});

Answer 2

数据将采用不同的形式，例如数据存储 DS （例如SQL Server），它们位于关系表中，数据访问层 DAL 中在数据模型（对象模型）中，如实体框架 EF ，在表示层 PL ，它们将在View Model中，在HTML页面或桌面形式上，它们将在住在 UI 组件中。

当一个图层调用另一个图层时，他们必须有一个通信通道和一个数据容器，可以将数据从一个表单更改为另一个表单。

每当 DAL 要求 DS 中的某些数据时，应将其从表格形式更改为对象模型表单，因此 DAL 会执行此操作不关心表格形式。当您将数据从 DAL 发送回 PL 时，应将其更改为View Model表单，并再次 PL 关心对象模型表格，等等。

你可能会问一下 BLL 层，我猜这个层大部分时间只是中间没有逻辑的委托，所以对于某些性能问题 PL 将直接访问 DAL 。

我希望这会回答你的问题。

编辑

对于 BLL ，您认为是系统的思想， PL 只显示它收到的内容， DAL 刚刚返回了什么要求通过获取正确的 DS 实体返回。所以CRUD将在 DAL 。

例如，您需要搜索员工列表， BLL 这里只是一个委托层，它将 PL 调用委托给 DAL < / strong>并返回结果。但是在添加新员工的情况下， BLL 将具有一个具有 AddNewEmoloyee 等功能的界面，该界面将执行一些业务逻辑功能，例如确保薪水符合相应到员工级别范围，然后它会在 DAL 中调用所需的 CRUD 操作。

什么放在业务逻辑层？

2 个答案: