问题标签 [separation-of-concerns]

您如何决定视图或控制器中是否有某些内容？

下面是一些具体的例子：

• Zend_Captcha：控制器生成验证码并将其传递给视图还是视图生成它？
• Zend_Alc：视图是否决定视图的一部分是否应该显示给用户，或者您是否有多个视图取决于可用的操作并且控制器选择正确的一个进行显示？
• Zend_Session：视图是根据会话数据跟踪谁在查看它，还是由控制器解析并作为某种参数呈现给视图？

哪些组件（模型、视图或控制器）应该执行哪些操作的规则或指南是否写在我可以查看的地方？我在 Zend Framework 站点的文档中没有看到这一点。

想象以下场景 - 我们有 Page1，其中包含控件 Control A 和 Control B。

假设控件 A 有一个按钮，单击此按钮时我们希望控件 B 做出反应。但是我们想以一种抽象的方式来做这件事，即我们不能让控件 B 知道关于控件 A 的任何事情，反之亦然。

这样我们就可以单独开发这些控件，并通过单元测试来驱动它们。

现在，我以为我有解决方案，只是想知道你们对此有何看法。

单击控件 A 的按钮时，我在 Session 上放置了一条“消息”，即 Session["MESSAGES"] = "ControlA_Click"。

在 Page1 中，在 Page_LoadComplete() 上，我调用了 ProcessMessages，如下所示：

在 ControlB 的 ProcessMessage() 方法中，我们可以对 ControlB 感兴趣的消息做出反应，如下所示：

对我来说，这似乎有效。它允许我们完全独立地开发这些控件，同时仍然允许在抽象级别进行控件间通信。

我能想到的唯一可能导致崩溃的可能是与页面和用户控件相关的 ASP.NET 生命周期。我认为它的方式是在拥有页面上调用 Page_LoadComplete() 之前，应该在控件上处理所有事件。

想法？

我们有一个分层的应用程序，或者至少正在过渡到一个，分解如下：

• 接口（用户接口或应用程序接口，即webservice等）
• 商业逻辑
• 数据访问

为了使这个问题的其余部分更加具体，我将描述一个具体的例子。

我们有一个用户界面，它背后有一个控制器对象（业务逻辑层）。该控制器通过另一个对象（数据访问层）与数据库通信。

在给定的上下文中，用户界面允许用户选择一个员工来绑定正在执行的操作。由于有关于用户（实际上是控制器之外的任何世界）可以选择哪些员工的规则，控制器为此提供了两件事：

• 一个可读的属性，其中包含可供选择的可用员工列表
• 包含当前选择的员工的读/写属性

用户界面可能会读取列表并使用它来填充组合框。

在此应用程序的版本 1 中，组合框包含员工的识别号 + 员工的姓名。

一切都很好...

...直到版本 1.1，一个错误修复。用户抱怨他无法在Jimmy Olson和Jimmy Olson之间进行选择，因为该应用程序无法让他轻松地知道哪个是哪个。他知道销售部门有一个 Jimmy，开发部门有另一个，所以这个 1.1 版本的解决方法是简单地在组合框中添加一个斜线 + 部门名称。在版本 2 中，我们会选择将组合框替换为具有列支持的组合框，删除斜线，但在 1.1 中，选择此选项是为了最大限度地降低出现更多错误的风险。

换句话说，组合框将包含：

• 1 - 吉米奥尔森/销售
• 2 - 吉米奥尔森/发展
• • 其他人

但是，用户界面代码没有 SQL 代码，也没有任何方法可以控制该部门，因此我们必须到控制器那里查看代码。控制者不需要部门，说实话，连员工的名字都不需要，身份证号码就够了，所以控制者里面没有任何东西向部门索要或做什么。所以我们必须深入到数据访问层并在那里更改 SQL。

坦率地说，这个解决方案很臭。

如果这个控制器有多个接口，有不同的要求，我们有三种可能的解决方案：

1. 更改数据访问层以满足多个接口（2 层之外）的（增加/多样化）需求，这意味着所有接口都可能获得它们需要的所有数据，但它们也将获得任何所需的所有数据其他接口的
2. 添加一些东西，让用户界面告诉数据访问层（仍然是 2 层）它需要什么
3. 以某种方式使用户界面层获得所需的数据，而无需更改所涉及的控制器或访问层，这听起来像是我们需要更多的数据访问代码，某处。

以上解决方案都感觉不好。

我想知道的是，我们完全偏离轨道了吗？你会怎么做？在上述 3 之下是否有第四和第五种解决方案？

根据这个问题：Separation of Concerns，接受的答案包含以下引用：

关注点分离就是将每个关注点的代码分开。更改接口不应该需要更改业务逻辑代码，反之亦然。

这是否仅仅意味着所有控制器/数据访问层应该为我们提供完成其工作所需的一切（即员工的识别号），然后用户界面应该与数据库对话并询问更多信息关于这些特定的员工？

我正在尽我所能设计我的 web 应用程序，并在层之间进行良好的分离。我正在使用存储库模式，因此有一个由我的 Web 前端调用的 ObjectService 调用的 SQLObjectRepository。

在我的对象模型中，用户与一个或多个区域相关联，这些区域应该过滤他们应该有权访问的对象。我的问题是，当我查询对象时，我是将代码放在服务中以设置对象的权限，还是该代码应该在存储库中？如果用户是 2 个区域的成员，我应该将用户作为参数传递给服务，还是应该将用户的区域传递给服务？

我有一个带有命令行界面的现有应用程序，我正在向该应用程序添加 GUI。经常出现的一种情况是我有一个继承自一个类的对象列表，需要在列表中显示，但每个子类的显示方式略有不同。

不想到处都有巨大的 switch 语句使用反射/RTTI 进行显示，每个类都知道如何返回自己的摘要字符串，然后将其显示在列表中：

类似的功能可以在不同的上下文中显示不同的信息。在我们需要添加 GUI 之前，这一切都很好。字符串已经不够用了——我需要创建图形控件。

我不想修改每个单独的类以便能够在 GUI 中显示它——特别是因为我们至少希望将它移动到一个 GUI 平台。

是否可以使用某种技术将此 GUI 代码从数据对象中分离出来，而无需使用 RTTI 和 switch 语句？如果能够取出 GetSummary 函数，那就太好了。

理想情况下，我能够有一个显示类的层次结构，可以采用数据类并根据运行时类型而不是编译时类型显示它：

这个问题与语言无关，但我是 C# 人，所以我使用 POCO 一词来表示仅执行数据存储的对象，通常使用 getter 和 setter 字段。

我刚刚将我的域模型重新设计为超级骗子 POCO，并且对如何确保属性值在域中有意义存在一些担忧。

例如，服务的结束日期不应超过该服务所依据的合同的结束日期。但是，将检查放入 Service.EndDate 设置器似乎违反了 SOLID，更不用说随着需要完成的验证数量的增加，我的 POCO 类将变得混乱。

我有一些解决方案（将在答案中发布），但它们有其缺点，我想知道解决这个困境的一些最喜欢的方法是什么？

当只有恶意数据集并且 microsoft 应用程序阻塞时，您在层之间的传输对象将是数据集/数据表或 DTO/POCO。我属于喜欢使用 DTO/POCO 的帮派。

现在随着 SubSonic、Entity Framework、NHibernate 等映射层的突然浪潮，我还应该使用我最喜欢的 POCO 吗？我主要这样做，当使用 ASP.net webforms 时，99% 的时间最终使用 ObjectDataSource 绑定到控件和特定于每种类型的功能。

我是否应该放弃对 POCO 的热爱并传递 IQueryables 或 Entities 或类似的东西并利用其他 DataSource 对象？

使用这些对象而不是 DTO 的优缺点是什么？它将如何影响我的应用程序设计和性能？

编辑：我什么时候可以使用其他数据源，如 Linq Datasorce 和 Entity 数据源等？

我过去读过一些关于模型的 MVC 建议，指出您不应该为域和视图重用相同的模型对象；但我找不到任何愿意讨论为什么这很糟糕的人。

我认为创建两个单独的模型——一个用于域，一个用于视图——然后在它们之间进行映射会产生很多重复，加上繁琐的映射代码（其中一些可能会被AutoMapper之类的东西缓解），这很可能容易出错。

是什么让为这两个问题建立一个单独的模型值得重复和映射代码的麻烦？

我想知道你是否认为有必要重构这个类。（关于关注点分离）

ReadMappingFromAttributes - 从类型 T 读取映射并将其存储在类中。有一个要使用的列表的名称和一些 csvMappingColumns，其中包含要设置值的属性的名称和 csvcolumns 的名称。

GetObjectsFromList - 使用 CVSListreader（通过构造函数传入）从所有行获取数据作为 KeyValuePair（Key = csvcolumnName，value = 实际上值），然后使用映射信息（listname 和 csvMappingColumns）将数据设置为物体。

我不能决定这门课是有两个问题还是一个问题。首先我觉得它有两个，并开始重构从行到对象到另一个对象的转换。但在此之后使用该功能感觉很尴尬，因为我首先必须创建一个映射检索器，然后我必须检索行并将其与映射一起传递给“映射器”以从行转换对象

/w

我一直试图围绕 DDD 以及它如何与 MVC 关联起来，但我在实体识别方面遇到了麻烦。

特别是，我试图保持我的表示、域和数据模型之间的严格分离。我的问题在于我如何跨这些边界保存实体标识。澄清一下，我使用不同的类来表示不同上下文中的同一实体 - 例如，我有一个“ShipmentRequest”域类、几个“ShipmentRequestView”表示类（取决于特定视图所需的属性）和一个'shipment_request' 数据库表（我的数据模型）。

我觉得使用“ID”属性（如 ShipmentRequestId）会违反我试图实现的分离，因为此 ID 属性是数据库问题，而不是域问题；而且我不想在层之间传递相同的对象，因为这意味着将不需要的数据传递到我的表示层。

我如何保持这种分离，同时跟踪这些层之间的身份？