问题标签 [separation-of-concerns]

我有一个“博客预览”模板——它基本上只是一个缩略图、标题和所述博客的简短摘录，采用简洁的结构，可以在列表中重复。

如上所述，我打算从我的模型中的数据库中提取我网站上的前 10 个博客，将它们传输到控制器，控制器将提供它们作为视图。在视图中，我需要遍历结果并为每个博客填充一个新的“博客预览”。

我当前的解决方案（我认为这可能会违反 MVC 的规则）是在视图模板中执行此操作：

不知何故，这感觉像是不应该允许视图做的事情？但是，我还能如何循环浏览主页模板内的“预览”模板？

帮助？

Response.Redirect在坚持正确的层分离的同时，在 Model-View-Presenter 模式中调用 a 的最佳方法是什么？

下面是来自 Ben Nadel 的演示单页长寿命 AJAX 应用程序的 JavaScript 模板示例，取自：[来源]

我想问一下使用这样的 JavaScript 模板引擎的目的是什么？是为了节省带宽吗？这只是关注点分离的问题吗？它有助于解决浏览器内存泄漏问题吗？

什么时候应该使用模板引擎，什么时候更容易使用原始 HTML AJAX 响应？

相关讨论：

JQuery 模板引擎

我有一个非常以数据为中心的应用程序，用 Python / PyQt 编写。我计划进行一些重构以真正将 UI 与核心分开，主要是因为还没有任何真正的测试到位，而且显然必须改变。

已经有一些分离，我认为我已经以正确的方式做了很多事情，但它远非完美。两个例子，告诉你什么样的事情困扰着我：

• 当用户右键单击一个数据对象的表示时，弹出的上下文菜单是由该数据对象创建的，尽管这个数据对象（本质上是一个数据库行的 ORM 表示）显然应该与 UI 无关.

• 当一些东西被写入数据库，但写入失败（例如，因为数据库记录被不同的用户锁定），经典的“重试/中止”消息框会呈现给用户。这个对话框是由数据提供者*创建的，尽管提供者显然不应该有任何 UI 功能。显然，提供者可以改为引发异常或以其他方式指示失败，并且 UI 可以捕获并采取相应的行动。

  _{* 这是我用来表示基本上代表数据库表并在其数据对象和数据库引擎之间进行调解的对象的词；我不确定这是否是通常所说的“提供者”}

我没有测试经验，所以我不容易“感觉到”可测试性问题或类似问题，但在我开始之前，必须进行一些重组。

不涉及复杂的业务逻辑（它主要只是 CRU D，是的，即使没有 D ），这将比重写更重组，所以我并不真正关心引入回归错误，就像在这个问题中讨论的那样。

我的计划是在开始重构时考虑到 UI 部分可以很容易地被替换为 Web 前端或基于文本的界面而不是 Qt 界面的想法。另一方面，核心仍然会使用 Qt 本身，因为在很多地方都使用了信号/槽机制，例如数据对象发出changed信号来指示，嗯，你知道什么。

所以，我的问题是：这是提高可测试性和可维护性的可行方法吗？任何其他评论，特别是考虑到 Python ？

我试图找到最好的方法来分离我的域逻辑和我的持久性逻辑的关注点。我正在使用 Linq-2-Sql 进行数据访问，并且一直在关注NerdDinner 教程。如果您查看第 40 页，您可以看到他们正在使用部分类来将业务规则用于他们的 Linq 生成的类。对我来说，这感觉不对（是吗？），我希望拥有自己的 POCO，这些 POCO 暴露在我的应用程序的表示层中。看起来这里的一个选项是使用单独的 DTO 类。这对我来说感觉更好，但它添加了更多代码来测试和维护。

我喜欢简单地添加部分类以在 Linq 类上强制执行业务规则，但我不喜欢将 Linq 类暴露给我的表示层，因为如果数据库发生更改，我也需要更新表示层。

DTO 方法感觉更简洁，因为如果数据库发生更改，我永远不需要更新表示层，但要处理的代码要多得多。

因此，我目前的方法是，两个类库一个带有 Linq-2-Sql DBML + 部分类，第二个带有一组只有自动生成的属性的类，然后是一个“repo”类，用于管理从Linq 组装并将其转换为IQueryable<T>.

有没有更好的办法？有更好的中间立场吗？我可以两全其美吗？如果是这样，您将如何将它们分成不同的程序集？

更新

也许，我真正需要做的是将所有 Persitence/Domain 逻辑整合到一个程序集中（与 NerdDinner 示例中使用的方法相同），然后在我的表示层中创建不同的“视图对象”，它们是非规范化版本我的 Linq-2-Sql 实体？

为什么有人不想使用文件隐藏代码，以便将服务器端代码与标记分开？这不应该是 .NET 相对于经典 ASP 的优势之一吗？

就个人而言，我认为将代码与标记混合会使代码更难理解。

我讨厌看到那些该死的 <% %> （服务器端块）与标记相互拼接，哎呀。我希望这在 ASP.NET 中只是为了与经典 ASP 向后兼容，但我总是看到 MS 的示例，其中包括那些黄色括号。

我正在尝试理解一个可在此处下载的代码示例，并且对为什么执行代码时此处显示的任何服务器端中断都没有中断感到困惑，即使我看到已在 web.config 中设置了该中断。由于我通常使用代码隐藏，因此我想知道 aspx 中的服务器端代码是否有一些处理方式不同的东西，这会阻止我调试 runat=server 代码。

所以。我的问题是：

1）为什么有人不想使用文件隐藏代码，以便将服务器端代码与标记分开？

2）为什么我不能打破服务器端的逻辑？

您对我的任何相关评论也欢迎您的见解和意见。

对于必须执行“GET”或“POST”，返回输出流，解析输出流，然后在界面上显示解析结果的 HTTP 请求调度程序，最好的设计模式是什么？

目前，我有一个 HttpRequestDispatcher.java，其中在其构造函数中定义了一个 UI 类，并在线程 run() 方法中，将结果发送到 UIClass.requestSucceeded 或 UIClass.requestFailed，然后在其中解析流并解析结果显示。

问题是我真的想要分离接口、解析器和调度程序之间的关注点。这样，在未来，我真的可以将调度程序与许多其他类一起使用......现在，我必须为每个“屏幕”拥有一个 HttpRequestDispatcher......

不胜感激任何建议，谢谢！

我正在尝试为我的大型 ASP.NET MVC 应用程序创建业务和数据层。因为这是我第一次尝试这种规模的项目，所以我正在阅读一些书籍，并努力小心地将事情正确地分开。通常我的应用程序混合了业务逻辑和数据访问层，并且多个业务实体交织在一个类中（当我试图弄清楚在哪里添加东西时，这让我困惑了几次）。

我一直在阅读的大部分内容是将业务层和数据层分开。这看起来一切都很好而且很花哨，但我无法准确地想象在某些情况下如何做到这一点。例如，假设我正在创建一个允许管理员向系统添加新产品的系统：

然后我通过创建一个存储库来分离数据访问

假设我想要求产品名称至少包含 4 个字符。我看不出如何干净地做到这一点。

我的一个想法是扩展 Name 的 set 属性，并且仅在它的长度为 4 个字符时才设置它。但是，创建产品的方法无法知道名称没有被设置，除了 Product.Name != 无论他们传入什么。

我的另一个想法是将它放在存储库中的 Add() 方法中，但是我的业务逻辑就在数据逻辑中，这也意味着如果 Add 调用失败，我不知道它是否失败业务逻辑或因为 DAL 失败（这也意味着我无法使用模拟框架对其进行测试）。

我唯一能想到的是将我的 DAL 东西放在从存储库中的 Add() 方法调用的第 3 层中，但我在我的书中或在任何领域建模示例中都没有看到这一点网络（我至少见过）。当我不确定是否需要它时，它也会增加域模型的复杂性。

另一个示例是希望确保名称仅由一个产品使用。这会放在 Product 类、ProductRepository Add() 方法中，还是放在哪里？

作为旁注，我计划使用 NHibernate 作为我的 ORM，但是，为了完成我想要的（理论上）我使用什么 ORM 并不重要，因为 TDD 应该能够将它全部隔离。

提前致谢！

简单的问题。我一定完全错了，但我认为值得问这个问题。

根据 MVC 中描述的关注点分离，在 View 中访问 ViewData[“Message”] 是否正确？

例如，在控制器中：

在视图中我们调用

另一种选择（不违反关注点分离）是在视图模型中设置消息。

例如在控制器中：

在视图中我们调用

任何想法都非常感谢。

在 Internet 上找到的每篇关于使用 ViewModels 和使用 Automapper 的文章都给出了“Controller -> View”方向映射的指导方针。您将域模型与所有选择列表一起放入一个专门的 ViewModel 并将其传递给视图。这很清楚也很好。
视图有一个表单，最终我们进入了 POST 操作。这里所有的模型绑定器连同[显然] 另一个视图模型一起出现，该视图模型[显然] 与原始视图模型相关，至少在命名约定部分是为了绑定和验证。

你如何将它映射到你的领域模型？

让它成为一个插入动作，我们可以使用相同的 Automapper。但是，如果它是一个更新操作呢？我们必须从存储库中检索我们的域实体，根据 ViewModel 中的值更新它的属性并保存到存储库。

附录 1（2010 年 2 月 9 日）：有时，分配模型的属性是不够的。应该根据 View Model 的值对 Domain Model 采取一些行动。即，应该在域模型上调用一些方法。可能应该有一种应用程序服务层位于控制器和域之间，以便处理视图模型......

如何组织此代码以及将其放置在何处以实现以下目标？

• 保持控制器薄
• 荣誉SoC实践
• 遵循领域驱动设计原则
• 干燥
• 未完待续 ...