问题标签 [separation-of-concerns]

我正在努力成为一个更好的开发者......

我正在使用的内容：

1. .Net MVC 框架 1.0
2. 实体框架 3.5

我一直在阅读，我想我想做的是：

1. 为域中的每个聚合创建一个存储库。例如，订单存储库将管理订单的 OrderItems。
2. 创建一个服务层来处理业务逻辑。每个存储库都会有一个具有相似方法的相应服务对象。
3. 在存储库和服务之间创建 DTO
4. 可能创建 ViewModels，它们是 View 使用的类。

我有一个基本存储库接口，我的聚合存储库接口将实现...

我的 Order Repository 接口定义如下……随着我对这个学习练习的深入了解，可能会有其他方法。

我的服务类与存储库的定义基本相同，只是每个服务实现都包含业务逻辑。这些服务将在构造函数中采用存储库接口（我还没有准备好在这个练习中使用 IoC，但相信这就是我想要结束的地方）。

1. 存储库实现将使用实体框架从数据库中推送和拉取。检索数据时；这些方法将只返回 DTO 而不是 EF 生成的对象
2. 服务（正如我所说的那样）将控制存储库并执行业务逻辑。这些服务就是您将在控制器中看到的，即_orderService.GetById(1)。
3. 这是我开始翻转并可以使用一些反馈的地方......我应该让我的服务类填充 ViewModel 类......我应该没有 ViewModel 类......也许从一种类型到另一种类型的映射太多？

我很想就我在关注点分离方面的前进方向得到一些反馈。

谢谢

即当 MVC 不是一个选项时，MVP 仍然是下一个最佳选择吗？

我想我会在这里问这个问题，因为我敢肯定还有其他像我一样的人没有机会参与一个新建项目，并且想要重构 Web 表单 UI 以更好地将表示与业务对象分离。 .

我正在开发一个遗留应用程序，其任务是添加相对较小的附加要求、增强功能和错误修复。

我在这里处理的应用程序部分可能被描述为一组对持久保存到关系数据库的业务对象的 CRUD 操作的 UI。

现有 UI 使用 MultiView 控件在关联业务对象（一对一关联或一对多/父子）的编辑之间导航。是的，没错 - 都在一页上。不幸的是，用户控件的使用非常少，因此标记和代码隐藏长达数百行。

在每个 View 上，FormView 通过各种 ObjectDataSource 管理业务对象上的 CRUD。在每个 FormView 的 ItemTemplate 中，各种服务器控件数据绑定到 ObjectDataSource 上的字段或方法。

我想介绍更多的关注点分离，并从 Page 代码隐藏中获取一些代码。

到目前为止，我的研究表明我可能会考虑：

1. 使用 Model View Presenter 的风格；更具体地说 -使用 Web 客户端软件工厂的 ObjectContainerDataSource可以更轻松地在当前 UI 和一组新的 Presenter 类之间建立桥梁。

2. 使用 MVC 框架从头开始重新构建（不是一个选项）。

3. 别管闲事；只有当我需要在不同的 UI 场景中重用我的演示文稿时，MVP 模式才合理？

如果我同意（3），我仍然想知道如何开始重构以更好地分离表示。

你会怎么做？任何其他想法都感激不尽...

这里有更多的背景知识供有兴趣的人参考：

该领域属于药物研究领域，但这无关紧要，您可以将其视为非常典型的业务线——一系列设置的用户配置，这些设置构成了应用程序另一部分的操作条件。

业务对象层已经以非常一致的方式构建。虽然我可能不喜欢它，但我不能证明改变它是合理的。每个对象都是它自己的存储库/数据访问对象，其中有“按 ID 获取”和“按标准获取列表”的静态方法。在可能的情况下，通用操作在抽象基类中实现。每个业务对象都将数据访问工作委托给数据访问层，该层利用 ADO.NET 2.0 提供者工厂机制保持相对于具体提供者的抽象。在这方面，它与使用 Microsoft 企业库中的数据访问应用程序块的任何应用程序有很多共同之处。

有相当详尽的用 NUnit 编写的集成测试，它们从头开始设置测试数据库，因此它们需要很长时间才能运行，但至少它们验证了这些东西是否可以正常工作（无论如何，在过去的某个时间点 ;-)。几乎没有真正的单元测试到位（还）。

在我的工作场所，我们正在计划对我们的核心产品进行重大重构，这是一个具有多个“模块”的 Web 应用程序。我引用了这一点，因为这是我们的主要关注点之一：模块并不是真正的模块，整个事情都是单片的。该应用程序是用 PHP 编写的，带有 smarty 模板，并使用 Pear 来访问 MySQL 数据库。我们并不真正关心数据库的独立性，尽管如果这不需要几个月的时间来实现就好了。

我们主要担心的是开发时间/成本呈指数级增长，因为在不相关的地方会出现错误，并且没有可靠的通用架构来依赖以获得最常见的功能（每个模块基本上都是从前一个模块复制/粘贴，然后适应）。

我对 web MVC 原理有一些经验，主要是在 ASP.NET MVC 方面。我喜欢它提供的清晰分离和可测试性。然而，当在本地机器上尝试这个时，应用程序比它应该的要慢很多。

好的，足够的介绍，关于问题： - 我应该依赖缓存模块吗？这是否消除了使用良好架构提供的大部分开销？APC之类的东西。

• 该应用程序主要是阅读。写入主要是单个值（更改记录上的单个字段）。任何擅长于此的 PHP 的 OR/M 吗？
• 也在寻找一个灵活的 MVC 框架。我知道 Zend、CakePHP，也许还有 Symfony？

棘手的部分是我们没有能力进行完全重写。我们将不得不逐步改进当前非常混乱的代码库。这必须在编写新代码或修复错误时完成。我真的非常喜欢能够做的一件事是在修复它之前为一个新错误编写一个回归测试，以防止它以后再次弹出（这种情况偶尔会发生）。

我目前正在考虑的堆栈包含：

• 选择的 MVC 框架
• 日志记录（log4php？）
• 选择的 OR/M（不必是动态的，代码生成也可以）
• 选择的 IoC 容器
• Smarty 模板，也许是抽象的，所以我们可以在需要时将其切换出来。
• 选择的操作码缓存（我们现在正在使用一个，忘记了哪个，必须询问系统管理员）

让我担心的主要一点是在 PHP 中创建干净的代码对性能的影响。看到它是一种与 .NET/Java Web 堆栈相反的解析语言，为其他内联代码创建抽象（在不同文件中强制分离）可能会在另一个层面上产生新问题。

注意：如果您想出更合适的标签，请重新标记，我不确定当前的标签。

什么时候设计模式会让你的软件变得更糟？

我看过一个程序，他们在 GUI 和逻辑之间使用外观模式。他们认为不能通过此传输任何对象，因此仅使用原始类型，这使得编码变得困难。

为了获得一些良好 OO 设计的实践经验，我决定尝试在遗留应用程序上应用关注点分离。

我决定我对这些分散在代码库中的调用感到不舒服。

虽然我之前已经通过编写一个帮助类将这些调用封装到静态方法中来解决这个问题，但我认为这可能是一个更进一步的机会。

我意识到最终我应该以使用依赖注入为目标，并且始终是“对接口进行编码”。但我不想迈出看起来太大的一步。与此同时，我想朝着这个最终目标迈出更小的步伐。

谁能列举他们推荐的步骤？

以下是一些我想到的：

• 让客户端代码依赖于接口而不是具体的实现

• 通过构造函数或属性手动将依赖项注入接口？

• 在开始选择和应用 IoC 容器之前，我如何保持代码运行？

• 为了实现依赖关系，任何需要配置值的类的默认构造函数都可以使用工厂（使用静态 CreateObject() 方法）？

当然，我仍然会对工厂有具体的依赖吗？...

我已经查阅了Michael Feathers 的书，所以我知道我需要介绍接缝，但我很难知道我什么时候介绍了足够多或太多！

更新

想象一下，客户端调用 WidgetLoader 上的方法，向其传递所需的依赖项（例如 IConfigReader）

WidgetLoader 读取配置以找出要加载的 Widgets 并要求 WidgetFactory 依次创建每个

WidgetFactory 读取配置以了解默认情况下将 Widget 置于什么状态

WidgetFactory 委托 WidgetRepository 进行数据访问，读取配置以决定应该记录哪些诊断

在上述每种情况下，IConfigReader 是否应该像烫手山芋一样在调用链中的每个成员之间传递？

工厂是答案吗？

为了澄清以下一些评论：

我的主要目标是逐渐将一些应用程序设置从配置文件中迁移到其他形式的持久性中。虽然我意识到通过注入的依赖项，我可以提取和覆盖以获得一些单元测试的优点，但我主要关心的不是测试太多，而是封装足够多，以至于开始不知道设置实际在哪里持续存在。

这是一个示例案例来详细说明：

我在我的视图中使用 ItemsControl 动态创建一个简单的条形图，并将项目绑定到我的 BarGraphViewModel 中的 BarViewModels 集合（每个包含百分比值）。每个条应该有不同的颜色。颜色应该从一个集合中选择，例如{Color1, Color2, ..}

集合本身是恒定的，但柱的数量将取决于具体情况。

一个简单的解决方案是创建一个简单的 BarViewModel，如下所示：

（为简洁起见，我省略了属性更改和验证实现）

现在我可以从我的 BarGraphViewModel 为每个百分比创建一个 BarViewModels 并传入从我的 Color 集合创建的适当的 ColorBrush。

然后在 Xaml 中，我将创建一个简单的 ItemsTemplate 来绑定到这些属性。

只是现在，由于它包含 SolidColorBrush 类型的属性，我的 ViewModel 依赖于 Presentation 框架，如果我想在另一个环境中使用它，则必须对其进行更改。

因此，这是否会破坏 MVVM 最佳实践，或者是否可以接受（您必须在某处划清界限，否则事情会变得太复杂）

我只是想看看其他人对此有何看法，以及是否有其他解决方案可以让 ViewModel 完全不了解表示层而不会变得太复杂。我可以想象 ValueConverters 可以提供帮助吗？

所以这个问题是从这里开始的（如何处理多个事件参数）。这个问题让我开始思考这个问题，但它的不同足以保证它自己的线程。

我正在创建一个游戏（出于娱乐和学习目的），并且想知道我是否使用了良好的设计标准。我想我可能已经在关注点分离上进行了 OTT，或者只是把整个事情弄错了，但我希望情况并非如此。重写它没有问题，因为我想学习“最佳实践”和它们的实际应用。

编辑

让我稍微解释一下这个游戏，它基于 Jawbreaker 一个在许多手机上发现的游戏（快速演示在这里找到）。目标是选择分组的球以将它们从比赛中移除并获得尽可能多的分数。

我正在尝试将其扩展一点，并使用不同类型的板，球以不同的方式移动，不同的球类型，球可能只是去他们被告知的地方，或者他们可能会沿途做一些事情。

所以这是我创建的对象的结构，第一行显示了 DLL 及其对象，第二行显示了这些对象引用的内容：

_{（来源：ggpht.com）}

这是我做 UML 的尝试：

替代文字 http://yuml.me/3279d2ac

单击此处链接到 UML 的完整页面，使其更大一些，希望更易于阅读

对象 DLL 包含游戏中使用的基本对象、球和棋盘。它们不包含任何关于它们如何对情况采取行动/反应的逻辑（球确实实现了 CompareTo 和 Equals 方法）。IBall 的实现可能有 X 个（对于 IBoard 也是如此，尽管我想象的不会那么多）。

InstanceManager DLL 被用作创建对象的一种方式，不确定这是 100% 需要的，它本可以在对象 DLL 中使用。工厂是具有各种重载方法来创建 IBall 对象的静态类。BallFactory 可以采用 BallType Enum、A Drawing.Color 对象等。 BoardFactory 非常相似。Jawbreaker 是一个单例对象，它处理诸如保存一个非常经常使用的随机对象和一些 GameConfiguration 数据（与本主题不太相关）之类的事情。

Engine DLL 是大部分工作发生的地方。LogicFactories 使用 BallType 和 BoardType 对象来创建相关的逻辑对象。逻辑对象用于控制 IBall 和 IBoard 对象的工作方式。BallLogic 告诉球在其事件触发时它可以做什么。例如，当一个球被选中时，会在 Ball Logic 上调用一个方法，说明板上 Y 上的 Ball X 已被选中。然后，球可以做任何它的类型的球应该/可以做的事情。BoardLogic 非常相似，它处理董事会的行为方式。

引擎对象是另一个单例，它是 GUI 与整个游戏交互的方式。GUI 不会直接实例化任何其他对象。

所以总结一下 IBall 和 IBoard 类只保存关于它们的数据，逻辑类处理所有功能。

我想知道的是：

1）这是一种明智的方法吗？

2）（通常）逻辑应该与对象/数据分开吗？

3）我是否在关注点分离方面走得太远了？

4) 关于设计/结构的任何其他意见

编辑

我使用几个单例的部分原因是为了简单地在一个地方访问数据而无需一直保持对象，也只是因为它是一个单一的游戏，不会扩展到高端或跨多台机器. 我确实知道它们不是很好，也不是我经常使用的东西，但感谢您的评论。

感谢您的想法和反馈。

通过查看多个 .NET 入门工具包，我注意到的一点是业务对象构造通常在客户端级别处理。然后，将业务对象传递给业务层进行操作，序列化到数据库等。不应该把这段代码抽象到业务层，让客户端只需要传递必要的数据吗？拥有一个只接受对象作为参数的 CRUD 抽象的业务层有什么好处吗？

在几个示例项目中，我看到了 ViewModels 用于将数据对象转换为字符串，以便在视图中使用。

ViewModel 通常有一个构造函数，它接收一个参数——一个数据对象。然后构造函数将填充 ViewModel 的各种属性（主要是字符串和整数）。

这可以防止视图中出现任何复杂的逻辑。

乍一看，这对我来说似乎是个好主意，因为它更充分地强制将视图与复杂逻辑分离。

例如，假设我的视图试图呈现数据对象的属性“大小”，大小是 1 到 3 之间的数字，表示“小/中/大”。

我的视图中没有 if/switch 语句，而是在我的 ViewModel 中有一个“SizeString”或类似的东西，并且 if/switch 语句将进入 ViewModel 构造函数。

有人不同意这种方法吗？

使用其他方法会更好吗，例如助手？如果是这样，为什么？

以希望在您的 ASP.NET MVC 网站的每个页面上都有一个“最新新闻项目”侧边栏为例。我有一个 NewsItemController，它适用于专注于 NewsItems 的页面。让新闻侧边栏出现在主页的 HomeController 上怎么样？或者任何其他控制器？

我的第一直觉是将选择前 5 个 NewsItems 的逻辑放在用户控件中，然后在母版页中调用该控件。这样，每个页面都会获得一个新闻侧边栏，而不必用 NewsItem 逻辑污染任何其他控制器。这意味着将逻辑放入我所理解的表示层中，该表示层通常会放入控制器中。

我可以想到大约六种不同的方法来处理它，但就关注点分离和其他相关流行语而言，它们似乎都不“正确”。