Question

我有一个ASP.NET MVC应用程序，正在寻找提高可读性，测试等的方法。目前，很多业务逻辑都在控制器中，我想把它移到另一个位置。

以下是我一直在使用的一个想法：实体框架为我创建实体类（例如Product，Customer）。为什么不创建部分类来存储业务逻辑？这是一个例子：

public partial class Product()
{
   public static List<Product> GetGreenProducts()
   {
       using(MyEntities db = new MyEntities())
       {
           return db.Product.where(p => p.Color == "green").ToList();
       }
   }

}

然后，在控制器中，我可以这样做：

public class ProductController : Controller
{
   public ActionResult GreenProducts()
   {
       return View(Product.GetGreenProducts());
   }
}

这种方法似乎1）非常简单2）非常干净3）可以轻松进行单元测试。

我认为这是一个相关的模式。任何人都可以发现这个或其他想法的任何问题吗？

Answer 1

这里有两个问题：

为什么不用业务日志扩展EF类（而不是控制器）？

简单。因为业务逻辑不应该耦合到EF，而不应该耦合到控制器。

基本上（这是我对OP评论的解释），为什么不把CRUD操作放在EF而不是控制器。给出的示例方法：UpdateLastModified它属于EF还是单独的服务？

UpdateLastModified已经远远超过了一个例子。您不应该创建更新实体列的方法。您还需要UpdateCreatedBy，UpdateName，UpdateId吗？我当然希望不是。 EF为您提供执行此类琐碎任务所需的所有工具。

ProductService应关注中间层问题，无论它们是什么。投影ProductEntity - ＆gt;等事情ProductDao你有什么。 <{1}}不应该存在。

关于设计模式，为什么不直接使用业务逻辑扩展Entity Framework类？

1 个答案: