Asp.net mvc 验证应该主要在DDD的上下文中在哪一层进行？

这个问题可能会被问上千遍，但答案中有很多困惑和矛盾

我询问有关域驱动设计上下文中的验证

验证主要在哪一层进行？ 对象处于无效状态是否可以接受？因为很多答案都说这没问题，主要是因为历史数据和业务规则可能会随着时间的推移而改变，加载历史数据可能会导致问题？ 许多实现都考虑在域层中抛出异常，并将消息映射到UI，尽管Martin Fowler建议！何时返回消息以及何时在验证上下文中引发异常？ 许多文章解释了一些要遵循的技巧或路径，比如在文章中，但在评论中，他们承认他们现在做的事情略有不同。这些模式仍然有效吗

我是否应该像框架一样使用它？如果我使用它，这个框架是否只在应用层中用作MVC注释的替代品

什么时候应该使用业务规则框架BRF？ 我知道这里有很多问题，但它们针对的是DDD中的相同点验证

注意：我不使用CQRS模式，因为它使应用程序非常复杂。

---

因此，我有域层、数据层、应用层RMVC和共享内核，实际上有几个不同的活动可以称为验证，它们的处理方式都有所不同

消息验证通常发生在尽可能接近边界的地方。当我收到HTTP请求时，我将验证请求本身是否格式正确，元数据中是否指定了正确的媒体类型，请求主体是否可以被干净地处理，生成的DOM是否具有所有必需的字段，已知的数据节点是否都是适当的类型，在我担心域模型的当前状态之前，请确保存在的值在允许的范围内

通常，这种验证的形式是将消息中的数据转换为域中值对象的图形；这通常看起来像工厂或建设者，他们知道如何获取与域无关的值类型，并将它们转换为特定于域的值。域模型通常不知道关于消息格式的任何信息，也不知道序列化JSON通常不是域问题

在从持久性存储读取值时，存在类似的关注点分离——值工厂知道如何从原语创建值，但不一定知道关于JSON或结果集等的任何信息

业务逻辑通常位于域模型中，它验证给定消息在给定域的当前状态下是否有意义

对象处于无效状态是否可以接受

对象处于无效状态是不可接受的

但也有无法访问的有效状态。账户负余额正成为公司的一项重大负债，因此引入了一项新的业务规则，以防止可能导致负余额的提款。这并没有改变鲍勃的账户余额为负的事实。它仍然是一个有效状态，只是一个新规则无法访问的状态

何时返回消息以及何时在验证上下文中引发异常

不要使用异常来实施应急管理

验证主要在哪一层进行

主要在域中，除了与基础架构相关的验证，例如xsd验证或json模式

对象处于无效状态是否可以接受？因为很多 回答说没关系，主要是因为历史数据和 业务规则可能会随着时间和加载历史数据而改变 可能会引起问题吗

这是可以接受的，因为验证是在域中完成的，不应该是这样。从业务的角度来看，对象不能处于无效的业务状态，但是，有时，如在现实生活中，流程可能处于无效/临时状态。我们称之为最终一致性，我建议你看看这个。最后，系统将处于有效状态，这就是问题的全部，如果它暂时无效，那么，维护这样的系统可能会付出更大的努力，但有时你别无选择

许多实现都考虑在域层中抛出异常。 并将消息映射到UI，尽管Martin Fowler建议 在验证中用通知替换引发异常！ 何时返回消息以及何时在验证中引发异常 背景

我不太喜欢域层的异常，除非这显然是一个先决条件。例如，一个输入对于一个fiel来说太大 d、 或者一个项目的负价格。如果您无法构建有效的业务对象，那么在我看来，这是一个非常有效的异常情况。如果这是一个商业案例，那么一条消息最合适

许多文章解释了一些要遵循的技巧或路径，比如弗拉基米尔 Khorikov和jbogard在他们的文章中，但在评论中，他们 承认他们现在做事有点不一样了。这些是图案吗 还有效吗

我应该使用FluentValidation这样的框架吗？如果我使用它，是这样吗 框架仅在应用程序层中用作 MVC注释

DDD中最好的建议是永远不要使用框架，Spring或JDBC可能会有所帮助，但一般来说，您应该手工操作。我们甚至手工编写了存储、应用程序服务、Oracle投影和事件总线。它更快，更易于维护，而且您可以学到更多。沃恩·弗农（Vaughn Vernon）在他的《实现域驱动设计》（Implementing Domain Driven Design）一书中给出了非常好的示例和一个项目，您可以看看：用Java编写

什么时候应该使用业务规则框架BRF

---

同样，不要使用框架

你的问题有直截了当的答案。所以我把答案放在没有背景的地方

验证主要在哪一层进行

服务器端和客户端都提供了更准确、更安全的应用程序。不管设计环境如何。对于服务器端，您可以采用不同的方法，如fluent验证或数据注释模型，或者使用集成库（如jquery unobtrusive ajax）将它们带到客户端。服务器端验证更为重要，因为需要验证CRUD操作以避免异常等。。。。 就您的问题而言，层是视图和模型数据访问

对象处于无效状态是否可以接受？因为很多 回答说没关系，主要是因为历史数据和 业务规则可能会随着时间和加载历史数据而改变 可能会引起问题吗

当您在数据库中显示或处理数据存储时，所需依赖项的必填字段或空值会引发错误，这是可以接受的。在这里，没有人谈论可能随着时间的推移而发生的变化。我们现在只考虑。我们使用模式和编程规则来创建灵活性/可维护性。验证和条目依赖项可以随时间而更改

许多实现都考虑在域层中抛出异常。 并将消息映射到UI，尽管Martin Fowler建议 在验证中用通知替换引发异常！ 何时返回消息以及何时在验证中引发异常 背景

在客户端显示异常对于开发日来说是一种很好的技术，或者将阻止数据更改/存储的错误通知相应的用户。考虑到这一点：有些系统实际上没有向最终用户显示额外信息的策略。某些报告会使应用程序更容易受到入侵。这完全基于您正在开发的软件类型。一个好的实践是在客户端显示一个简单的错误，并在服务器内部存储错误日志，其中包含全面的详细信息

许多文章解释了一些要遵循的技巧或路径，比如弗拉基米尔 Khorikov和jbogard在他们的文章中，但在评论中，他们 承认他们现在做事有点不一样了。这些是图案吗 还有效吗

有些人可能有自己命名的个人架构。但其中一些是官方的，并被广泛使用，如工作单元或存储库模式，它将一些层添加到著名的模式MVC中，以实现更准确、干净和可维护的代码/应用程序。遵循任何模式背后的主要目的

我应该使用FluentValidation这样的框架吗？如果我使用它，是这样吗 框架仅在应用程序层中用作 MVC注释？我应该何时使用业务规则框架BRF 相反

FluentValidation是与FluentAPI类似的数据注释的替代方案。请注意，两者都用于为属于已定义的a类数据库表的属性定义规则。有一个名为ViewModel的概念，它包含一个转换，主要针对前端的验证对主模型类表进行了一些更改。您可以在项目中使用这两种方法，将每个模型映射到其ViewModel，反之亦然。如果您使用的是存储库模式，比如说，有一个数据访问层，那么一些验证就在这个层中。如果您使用的是ViewModel，那么它位于应用程序层内部。但是，作为建议，这些都是毫无价值的。成功的关键在于理解任何技术/架构/模式背后的主要目的。你可以在每一篇文章中找到大量的文章，并关注它们的目的，然后你可以决定做什么来让它们更干净/标准/可维护/灵活/等等。。。代码

最后一点提示：增加模块化增加了集成软件的成本，尽管降低了每个模块的成本

---

乌莱。为您的项目使用适度的设计。结合架构有时不仅不是一个好主意，而且还会增加成本和开发难度。非常感谢

中的更多详细信息，但我这里主要关心的是域模型层中的业务规则验证，而不是琐碎的输入验证，请您帮助我回答其余问题。我想问一下，即使在应用层也不建议使用FluentValidation framework吗？因为我们已经使用了MVC注释。我只会在表示层使用框架，例如Angular和，我倾向于不再走这条路…我可以问一下，不使用任何框架的建议是否也适用于AOP（如post c）？AOP在某些情况下很好，例如事务支持或更技术方面，例如在调用应用程序服务方法后刷新消息日志。沃恩·弗农（Vaughn Vernon）有一些用Java编写的示例，您可能会看到：事务方面也许这会有所帮助。@plalx这是一个非常好的答案，但它只回答了我问题的一部分，如果您能帮助我回答我的问题，我将不胜感激。