放什么在业务逻辑层？ [英] What to put in Business Logic Layer?

问题描述

我看了很多文章，他们似乎改变从一个作者/开发商下。在我的情况，我想这个设置的测试项目：

1. 通过ASP.NET MVC presentation层




2. 服务层（我的计划是ASP.NET MVC的Web API，这是在不同的组装）




3. 业务逻辑层




4. 使用EF DAL

有些文章说我不应该把CRUD操作上BLL和BLL应该只包含业务逻辑。此外，也有人说BLL不应该访问DAL。但是，如果一个业务逻辑需要存储在数据库计算/逻辑工作数据？我想我的问题是：

1. 如果BLL不应该访问DAL，如何在数据库需要的数据它能够执行逻辑对于那些商业逻辑？




2. BLL都是实体，对不对？他们是一样的POCO或者我仍然有POCO在DAL？




3. 此外，是在的DbContext BLL？有人说，它应该让我很困惑。




4. 有关BLL无CRUD什么？我应该怎么办呢？




5. 库接口是DAL？

补充意见/建议/什么我计划设置信息将是非常欢迎的（即使它是不相关的BLL）。

解决方案

我曾在一个项目上，前一段时间。

我们的项目arquitecture ressembled给你的建议是什么。

我们有一个ASP.NET MVC的网站，该网站访问的WEB API（在外部解决方案）。

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

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

我们曾在WEB API项目的业务逻辑。我们将创造，处理和实体从WEB API HTTP方法中储存。

但我们没有直接访问数据和持久层，我们有一个中间层，我们把它称为实体管理器。这些管理者在我们的Web API控制器（我们使用 Ninject 获得的依赖注入注入），并会处理创建实体，并且还持续存在，因此我们分离的一切。

这个方法工作对我们非常好，我们做了一个pretty以及可维护性和可扩展性的项目。

我希望这可能是对你的帮助，当然，也可能存在更好的技术。

PS：

我们使用的entites的经理提供给我们一个IRepository接口坚持的实体。这是我们对持久层的访问。内在逻辑，如持久性策略（如EF英孚的DbContext或文件IO）将内部的持久性项目。

---

这是我们的经营业务逻辑在我们的Web API的HTTP方法之一的例子：

  //库是一个IRepository＆LT;实体GT;
entityManager.Transaction（（资料库）= GT; {
     实体ourEntity = repository.CreateNew（）;     //某种程度上操纵实体     repository.Add（ourEntity）;
}）;
 

I have read lots of articles and they seem to vary from one author/developer to the next. In my situation, I am thinking about this setup for testing a project:

1. Presentation Layer via ASP.NET MVC

2. Service Layer (my plan is ASP.NET MVC Web API; this is on separate assembly)

3. Business Logic Layer

4. DAL using EF

Some articles said I should not put CRUD operations on BLL and BLL should only contain business logic. Also, some said BLL should not access DAL. But what if a business logic needs data stored in DB to calculate/work on logic? I guess my questions would be:

1. If BLL shouldn't access DAL, how about those business logic that needs data in DB for it to be able to perform the logic?

2. BLL are entities, right? Are they the same as POCO or would I still have POCO in DAL?

3. Also, is DBContext in BLL? Some say it should so I'm confused.

4. What about the no CRUD in BLL? Should I do that?

5. Repository interface is in DAL?

Any additional comments/suggestions/information on what my planned setup would be very welcome (even if it is not related to BLL).

解决方案

I worked on a project some time ago.

Our project arquitecture ressembled to what you suggest.

We had an ASP.NET MVC site, which accessed a WEB API (in an external solution).

The WEB API also referenced an external solution entirely made up of static libraries, which contained the data layer (just entities) and the persistence layer.

We also had Data Transfer Objects (MSDN) for communication between the web service and the clients, and to decouple the entities entirely from external solutions.

We had the business logic in the WEB API project. We would create, manipulate and store the entities from within the WEB API HTTP methods.

But we didn't accessed the data and persistence layer directly, we had an intermediate layer, we called it entities manager. These managers would be injected on our WEB API controllers (We used Ninject for Dependency Injection) and would handle the creation of the entity, and also the persistence, so we'd decouple everything.

This approach worked very well for us, and we made a pretty well maintainable and scalable project.

I hope it may be of help for you, and of course, there probably exist better techniques.

PS:

We used an IRepository interface provided to us by the entites manager to persist the entities. This was our only access to the persistence layer. Inner logic, such as persistence strategies (like EF's DbContext, or File IO) would be internal to the persistence project.

---

This is an example of our bussiness logic in one of our WEB API HTTP methods:

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

     //Manipulate the entity somehow

     repository.Add(ourEntity);
});

这篇关于放什么在业务逻辑层？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！