DAL,模型层,EF代码优先和业务逻辑,它们如何组合在一起？

Question

每比特一点,我是不成熟的,并且对ASP.NET MVC4越来越熟练.但是,我仍然没有在这个非常重要的问题上清楚地表明这一点.让我们说我有一个模型:

public class WorkPaper
{
    public int WorkPaperID { get; set; }
    public string name { get; set; }
    public string description {get ; set; }
    public bool verified {get; set;}
    public DateTime dateAdded {get; set;}

}

我使用此模型与实体框架代码第一种方法,我有以下数据库上下文:

public class NicodemeContext : DbContext
{
     public DbSet<WorkPaper> Workpapers { get; set; }
}

我不明白的是:什么是模型层以及什么是数据访问层.对我来说,WorkPaper类往往是DAL的一部分,因为我设计它并选择我的属性名称和类型(导航属性等...)以适应EF模式.但问题是,如果我是对的,我真的不知道应该把业务逻辑放在哪里.

在这种特定情况下,如果我想添加一条规则,说明如果尚未经过验证就无法发送工作文件,而另一条规则说如果超过2周之前已添加工作文件则无法提交(奇怪的规则)但那只是一个例子).我应该在哪里添加它们？我是否必须创建另一个类,但是我应该把它放在哪里以及它应该包含什么？对于我已经拥有的课程,这不是很多余吗？但另一方面,由于该类是"面向数据库",在那里添加业务规则不是很麻烦吗？

我的观点是真正理解我必须放置业务逻辑并理解DAL和模型之间的区别.我很难识别DAL和模型层,因为它们看起来与我非常相似.我想以正确的方式做事.

(基本上,我不知道在哪里用MVC编写"我的程序"!一旦我想编写我真正感兴趣的功能,我就不舒服了.我觉得我做的不对)

Answer 1

没有一种"正确"的方法可以做到这一点.可能存在许多"错误"的方式,但与大多数事情一样,"它依赖于".

你会发现很多意见.其中很大一部分取决于你如何接近它.例如,@ Tarzan建议将您的模型用于业务逻辑和数据层实体.其他人建议创建单独的Entity对象,业务对象和视图模型对象.

如果您正在制作一个相对简单的CRUD类型应用程序,那么您可以像@Tarzan所建议的那样做并且几乎没有问题.但是,在更复杂的应用程序中,您开始遇到这样做的问题.例如,当您的业务逻辑与数据逻辑不同时会发生什么？如果将它们组合成一组实体,那么您不得不在任何地方使逻辑相同,或者花费大量时间进行改造.

最灵活的方法是使您的演示文稿,业务和数据层完全分开.这样,(例如)UI的要求不需要与其他层匹配.(这是一个简单的例子,想象一下,对于某些类型的对象,允许特定字段为空,但不允许其他字段.您的数据层只知道该字段可以为空,而您的业务层将知道某些对象可以不行.)

但是,这种方法可能会产生大量开销,并且需要在每一层中看起来像重复的代码......创建了大量的额外工作,对于小型或简单的应用程序来说,这通常是不值得的.

要记住的一件重要事情是MVC是一种Presentation模式.这意味着它只关注用户界面."模型"通常被认为是"视图模型",它是视图使用的模型.此模型是根据视图要求定制的.例如,通过使用您不会放在数据模型上的数据属性.

如果您认为MVC是严格表示的,那么MVC不关心您正在使用什么类型的数据访问,也不关心您正在使用哪种业务层.它可以是服务层,存储库或业务对象库(例如CSLA).

MVC应用程序中的常见模式是使用某种类型的服务层,或者如果您只是执行CRUD操作则使用存储库.每层之间通常都有某种映射系统,使用AutoMapper或自定义构建映射类等技术.

这里的要点就是这个.MVC并不关心业务和数据,因此不要让自己全都了解这些如何适应MVC应用程序.他们没有,或者至少他们没有非常基本的接口.

您的应用程序是一组对象,可以视为一种体系结构.该体系结构由不同的层组成.MVC,服务,数据等.MVC可能是主要的用户界面,但这并不意味着其他一切也都是MVC.