的ASP.NET Web API库模式服务层（业务逻辑）

我只是完成使用Ninject依赖注入到我的asp.net网站API项目实施库模式&工作单位。的ASP.NET Web API库模式服务层（业务逻辑）

使用实体框架作为我的ORM。

我有以下soluction结构（项目）：

Web应用程序（asp.net网页API）
数据（的DbContext，资料库）
接口（IRepository等）
模型（来自DB的POCO类）

例如我的PersonRepository（数据项目）：

public class PersonsRepository : EFRepository<Person>, IPersonsRepository 
      { 
       public PersonsRepository(DbContext context) : base(context) { } 

       public IQueryable<Person> GetByAge(int age) 
       { 
        return DbSet.FirstOrDefault(ps => ps.age == age); 

       } 

    public void Delete(int personId, int age) 
      { 
       // Here I want to validate some stuff before deleting 
       // Business Rules need to be here!! 

       var attendance = new Attendance {PersonId = personId, Age = age}; 
       Delete(attendance); 
      } 

      }

所以我的问题是，如果它的正确实施我的存储库方法中的所有业务逻辑？以及在需要的情况下返回消息或验证的最佳方式是什么。

谢谢，感谢任何帮助！

来源

2014-03-27 VAAA

不，它不是。存储库实现属于持久性（DAL）。存储库涉及将业务对象转换为/来自用于将其存储到数据库中的任何形式。关心业务逻辑不是它的责任。业务逻辑保留在域中的业务层中。

商业逻辑是由域对象和服务包含。它永远不会出现在业务层之外，不在UI（控制器）中，而不在DAL（存储库，EF等）中。

您正在使用的仓库实现是不正确，反模式，因为它违背了一个资料库的目的：解耦从持久性细节的业务层（EF是一个实现细节）。存储库的接口不应该公开诸如IQueryable或EF实体之类的细节。它应该只知道关于业务对象的信息。

您的解决方案的结构是没有意义对我说：你使用的所有接口应该是在他们所属的层（库接口是业务层的一部分，这就是为什么它不应该知道EF）。模型，基于你的描述似乎是持久性模型（它应该是数据的一部分）。

你想要一个业务（域）层，在那里型号的真正意义的商业模式。不要与持久化模型（由EF使用），视图模型（由View使用）或MVC中的M（由控制器使用）混淆:)。 MVC中的M表示业务模型的一部分，但与业务模型不同。

我建议把你的时间多读一些关于存储库模式和3层架构，并确保你理解的概念和他们的目的。

来源

2014-03-27 16:39:17 MikeSW

其实我参考了John Papa Code Camper项目：https：// github。com/johnpapa/CodeCamper 在我有的示例代码中，该存储库模式是自定义存储库的自定义实现...因为GetByAge方法只会被PersonRepo使用 – VAAA

因此，您告诉我的是业务规则或逻辑（检查某些字段是否正确，如果条件为真或模型项目中的哪些内容（我拥有POCO类）？ – VAAA

业务逻辑应该停留在业务逻辑层，而不是数据访问 – MikeSW

Data和Web之间应该有一个名为Business的新层。 Web将仅引用业务层，业务层仅引用数据层。因此，在调用数据层之前或之后的业务层可以实现所有的验证和业务逻辑。

来源

2014-04-09 17:12:13 sunil

的ASP.NET Web API库模式服务层（业务逻辑）

回答

相关问题