问题标签 [architectural-patterns]

在企业应用架构模式中，Martin Fowler 谈到了组织领域逻辑的两种模式：领域模型和服务层。领域模型模式是“纯 OOP”方法，其中模型（可能使用 ORM 从数据库中查找的那些对象）包含业务逻辑（尽管可能只委托给另一个类中的逻辑）。

服务层模式类似于域模型模式，但在它前面有一个薄层，包含可以执行的业务操作。在 MVC 中，控制器主要与服务层交互。我相信大多数设计良好的 MVC Web 应用程序都使用这种模式。

现在，我的问题。Martin 建议域模型方法是更面向对象的方法，因此更好。以我的经验，在实践中实施非常困难（参见：不可能）。

以上面第一张图中给出的例子为例。有两个“实体”Contract和Product。这些通过映射器持久化到数据库中。在示例中，有一个RecognitionStrategy. Martin 将委托给包含实际业务逻辑的策略的方法放在实体本身中；contract.calculateRecognitions客户端使用or执行此计算contract.recognizedRevenue(someDate)。在实现类似的设计时，我通常将客户端界面编写为strategy.calculateRecognitions(contract)和strategy.recognizedRevenue(contract, someDate)。这使得服务层对于协调策略和合同是必要的。使用的具体策略被注入到服务中。

从设计的角度来看，Martin 的方法肯定更具吸引力，但围绕设置的工作要困难得多：

1. 在实例化 a 时传递策略Product是一种痛苦。您需要Product通过带有要使用的具体服务的工厂来创建 s，然后在创建实体时将其传递给实体。
2. 对数据库访问的细粒度控制较少。根据 ORM 设置，Contract委托给Product每个Product. 当我们加载ProductaContract但不打算调用contract.calculateRecognitions(). 我的方法为我们提供了更细粒度的控制，因为服务具有数据库抽象层的知识，而实体不应该。

我敢肯定，在实践中还有更多的痛点我在这里没有一一列举。

Martin 的方法有哪些具体优势可以说服我使用纯数据模型模式？

考虑以下视图结构：

• 布局视图
  • 地图视图
  • 列表显示
    • 项目视图
      • 列表显示
        • 项目视图
        • 项目视图
    • 项目视图
      • 列表显示
        • 项目视图
        • 项目视图

目前，我对整个结构只有一个控制器。所有嵌套视图都通过冒泡事件与该控制器进行通信。

我想为每个级别创建一个控制器吗？我有什么工作，但我觉得我的布局视图和列表视图做得太多 - 例如，当控制器说“这里是更新的项目列表（来自服务器）”时，布局视图负责删除地图不属于新数据的标记，更新现有的，并添加新的。同时，LayoutView 的第一个 ListView 负责做同样的事情，但它的项目。

为每个控制器创建一个控制器会更好吗？如果是这样，我会怎么做？布局视图是否应该注入一个 ListController 和一个 MapController，它们将负责构建子视图？

如果对技术感兴趣：这是针对 JavaScript 小部件的。

如何使用 C# winforms 中的 MVP 模式将多个表中的数据显示到我的视图中？

假设我有以下表格：

1. 水果

2. 颜色

   /li>

然后在我的解决方案中，我为每个表创建了类，即 Fruit 和 Color 类，具有自己的 getter 和 setter 以及表示数据库中表的其他详细信息。

然后我还为水果和颜色创建了两个模型。

因此，如果我想创建一个显示有关颜色记录的视图，我将使用我为颜色创建的模型来检索颜色集合（例如List<Color>）。如果我使用 DataGridView 来显示该记录，我会得到类似以下的内容：

对于 Fruit 记录，我可以使用上面相同的方法，但我需要显示颜色名称而不是颜色 ID，如下所示：（假设我使用的是 DataGridView 或自定义控件）

我想我可以为它创建另一个类并将其命名为“FruitColor”，然后为其赋予与上面的 Fruit 类相同的属性，但不是具有颜色 id 属性，而是用颜色名称替换它......但我我不确定这是否是 MVP 中正确的做事方式。我想我应该向你们询问有关如何正确操作的任何提示...

我没有在我的项目中使用 ORM，因为我想了解如何手动操作......但我也将不胜感激与使用 ORM 相关的任何帮助。我也是 3 周前才开始了解 MVP，所以我真的希望能得到任何帮助。

如果我有两个对象，即Fruit' andColor ，它们的定义如下：

如何将集合绑定Fruit (e.g. List<Fruit>)到 DataGridView？结果输出将类似于以下内容：

并且不喜欢下面的输出：（注意：NN.Color表示对象颜色的命名空间）

更新 #1：我在 SO 上找到了
一个类似的帖子，并尝试了该帖子的一些建议，但它不起作用......

我有一个更普遍的问题，关于如何在 MVC 模式中划分模型、视图和控制器的代码和职责。为了更好地理解，我将使用一个示例案例。

我的问题

应用程序分为模型、视图和控制器。在模型级别的某些操作期间如何处理应显示在视图中的错误？

我想到了两种可能：

a) 模型保存错误字符串并通知控制器和视图。然后视图从模型中轮询错误字符串并保存它。之后控制器告诉视图显示错误。

b) 模型将错误返回给控制器，控制器将其传递给要显示的视图。

你会说什么最适合 MVC 模式？或者什么更接近 MVC 模式？

非常感谢您提前

我正在实施存储库和工作单元模式；但是我没有将我的工作单元放在控制器中并在控制器中拥有业务逻辑，而是实现了一个请求/处理程序来划分这个逻辑。拆分工作单元并让我的控制器通过请求/处理程序访问有什么缺点吗？请参见下面的代码示例：

通用回购：

工作单位：

然后我为我的每个模型创建一个请求/处理程序并在其中实例化工作单元：

控制器将访问请求/处理程序：

注意：将有多个请求/处理程序实例化工作单元实例。由于工作单元的目的是将上下文保持在一个实例中，这会导致问题吗？

提前感谢您的反馈！

在我的代码中，我有许多具有此签名的函数（参数 + 返回类型），它们都使用相同try-catch的子句。

现在，这被一遍又一遍地复制，我知道复制是不好的。发生这种情况的原因是因为我希望代码能够返回多个HttpStatusCodeResult，但我不知道更好的方法。

在此示例中，我返回一个内部服务器错误和一个 OK 答案。但是如果我想返回另一种类型的错误呢？

在我的代码中是否有一种模块化的行为方式，无需复制？有我可以使用的设计或架构模式吗？如果有，是哪一个？

我试图了解这两种模式，并想知道它们的相似之处和不同之处。对我来说，它们在某些方面很相似，因为它们似乎都使用了一步一步的过程。有人可以对这两种模式有更多的了解吗？我是否说管道和过滤器模式将用于更大规模的应用程序和构建器模式用于小型应用程序？抱歉继续说，但在构建器模式中，所有步骤是否同时发生，即在返回完成的对象之前传递给构建器的所有属性？

谢谢。

在文献（博客、文章、关于企业架构的书籍……）中，似乎在 EA 中存在一个真正的（和专有的）SOA 应用。如果我们认为 DDD 和 SOA 共享共同的架构原则，但在许多其他方面存在差异，那么 DDD 在 EA 学科中的位置是什么？

是否有一种标准设计模式可以用来按顺序使用队列中的消息，但具有高可用性？

当然，我可以按帐号最后一位数字将负载分成单独的队列（顺序仅对每个帐户很重要），这给了我可扩展性，但是如果主机处理以“2”结尾的帐号失败，例如，我需要一些东西拿起那个负载。

我认为这种处理有一个标准模式。不幸的是，我无法使消息具有幂等性，因为队列源是由第三方集成造成的。

任何想法都非常感谢。