“业务逻辑层”适合MVC应用程序在哪里?

首先,在任何人尖叫之前,我很难用一个简单的标题来概括它。 另一个标题可能是“域模型和MVC模型有什么区别?” 或“什么是模型?”

从概念上讲,我理解一个模型是视图和控制器使用的数据。 除此之外,对于模型的构成似乎有很多不同的观点。 什么是领域模型,与应用程序模型,视图模型,服务模型等等。

例如,在最近一个关于存储库模式的问题中,我被告知空白,存储库是模型的一部分。 但是,我已经读过其他观点,认为模型应该从持久模型和业务逻辑层分离。 毕竟,不是Repository模式应该将具体的持久化方法与模型分离吗? 其他人说,域模型和MVC模型是有区别的。

我们举一个简单的例子。 包含在MVC默认项目中的AccountController。 我已经阅读了几个意见,包括帐户代码是糟糕的devise,违反SRP等..如果要为MVC应用程序devise一个“适当的”成员模型,那会是什么?

你将如何分离模型中的ASP.NET服务(会员提供商,angular色提供商等)? 或者你会呢?

我看到它的方式,模型应该是“纯粹的”,也许与validation逻辑..但应该是与业务规则(validation除外)分开。 例如,假设您有一个业务规则,即在创build新帐户时必须通过电子邮件发送某人。 在我看来,这并不属于模型。 那它属于哪里?

有人在乎这个问题吗?

我做到这一点的方式 – 而不是说是对还是错,是有我的观点,然后是适用于我的观点的模型。 这个模型只与我的观点相关 – 包括数据注解和validation规则。 控制器只包含build立模型的逻辑。 我有一个服务层,其中包含所有的业务逻辑。 我的控制器调用我的服务层。 除此之外是我的存储库层。

我的域对象分开安置(实际上在他们自己的项目中)。 他们有自己的数据注释和validation规则。 我的存储库在将它们保存到数据库之前validation我的域中的对象。 因为我的域中的每个对象都从内置了validation的基类inheritance,所以我的存储库是通用的,并validation了所有内容(并要求它从基类inheritance)。

你可能会认为有两套模型是代码的重复,并且在一定程度上。 但是,有一些完全合理的情况,域对象不适用于视图。

例如在使用信用卡时 – 在处理付款时我必须要求一个cvv,但是我不能存储cvv(这样做可以罚款50,000美元)。 但是,我也希望你能够编辑你的信用卡 – 更改地址,姓名或到期date。 但编辑它时,你不会给我编号或简历,我当然也不会在页面上以纯文本的forms显示你的信用卡号码。 我的域名具有保存新信用卡所需的这些值,因为您将它们交给我,但是我的编辑模式甚至不包括卡号或cvv。

这么多层的另一个好处是,如果架构正确,您可以使用结构图或其他IoC容器,并交换部分,而不会对应用程序造成不利影响。

在我看来,控制器代码只应该是针对视图的代码。 显示这个,隐藏,等等。服务层应该为你的应用程序的业务逻辑。 我喜欢把所有的东西放在一个地方,所以很容易改变或调整一个商业规则。 存储库层应该是相对愚蠢的 – 没有业务逻辑,只能查询你的数据并返回你的域对象。 通过将视图模型从领域模型中分离出来,您在自定义validation规则方面拥有更多的灵活性。 这也意味着您不必将隐藏字段中的每个数据转储到您的视图中,并在客户端和服务器之间来回推送(或在后端重新构build它)。 然后,您的视图模型将只保存与视图相关的信息 – 并且可以自定义为视图逻辑或计数或枚举的布尔值,以便视图本身不会被复杂的逻辑语句混淆

<% if (!String.IsNullOrEmpty(Model.SomeObject.SomeProperty) && Model.SomeObject.SomeInt == 3 && ...) { %> 

尽pipe一切似乎都是分散的,而且是分层次的,但它有一个被这样构build的目的。 这是完美的吗? 不是真的。 但是我更喜欢过去从控制器调用存储库的devise,并将控制器,存储库和模型中的业务逻辑混合在一起。

我经常想知道MVC元素究竟是如何适应传统的Web应用程序结构的,这些Web应用程序结构中有视图(页面),控制器,服务和数据对象(模型)。 正如你所说,有很多版本的。

我相信这个混淆是因为上面提到的被广泛接受的架构,它使用了“贫血域模型”(所谓的)反模式。 我不会详细讨论贫血症数据模型的“反模式”(你可以看看我在这里解释的东西(基于Java的,但是与任何语言相关的))。 但总之,这意味着我们的模型只包含数据,而业务逻辑则放在服务/pipe理者中。

但是,让我们假设我们有域驱动的架构 ,我们的域对象是他们所期望的方式 – 既有状态逻辑又有业务逻辑。 而在这个领域驱动的angular度来看,

  • 该视图是UI
  • 控制器收集UI的input,调用模型上的方法,并将响应发送回UI
  • 这个模型就是我们的业务组件 – 持有这些数据,还有业务逻辑。

我想这个答案是你的主要问题。 当我们添加更多的图层时,情况会变得复杂,比如库层。 通常build议应该由放置在模型中的业务逻辑调用(因此每个域对象都有一个对存储库的引用)。 在我链接的这篇文章中,我认为这不是最好的做法。 事实上,拥有一个服务层并不是一件坏事。 顺便说一下,领域驱动devise不排除服务层,但它应该是“瘦”,只有协调域对象(所以没有业务逻辑)。

对于被广泛采用(无论好坏)的贫血数据模型范例,该模型既是服务层又是数据对象。

我的想法是,

模型 –

不应该包含业务逻辑,它应该是可插入的(WCF类似的情况)。 它被用来绑定到视图,所以它应该有属性。

商业逻辑 –

它应该放在“域服务层”,它是完全分离的层。 此外,在这里将添加一个“应用程序服务”层。

应用程序服务与域服务层交谈以应用业务逻辑,最后返回模型。

所以,Controller会要求Application Service for Model,stream程就会像这样,

  Controller->Application Services(using domain services)->Model 

MVC模式和Asp.net框架没有区分模型应该是什么。

MS自己的例子包括模型中的持久化类。 你关于成员在模型中的问题。 这取决于。 你的模型中的类是由什么东西所拥有的? 有谁login和显示哪些数据之间有联系? 有没有过滤可编辑的权限系统的数据部分? 是谁最后更新或编辑了你的域的对象部分,因为在别人需要看到它或后端支持?

电子邮件的例子也取决于。 您是否熟悉域事件或特别事件? 你有一个单独的服务来发送电子邮件? 发送电子邮件的行为是否是您的域的一部分,还是您系统范围之外的应用程序级别的问题? 用户界面是否需要知道电子邮件是否成功发送? 发送失败的电子邮件需要重试吗? 发送的电子邮件内容是否需要存储以获得支持或客户服务要求?

这些types的问题过于宽泛和主观,但我正在回答,所以你和投票给你的每个人都可以理解这一点。

您的需求/时间表/资源都stream失到您系统的架构中。 即使是收入模式也能起作用。 你也必须考虑你正在拍摄的模式。 DDD与持久化模型应用程序有很大不同,它们之间的所有关系对于某些应用程序也是有效的。 你正在拍摄testing应用程序? 所有这一切都有效果。