问题标签 [separation-of-concerns]

在阅读 ASP.NET MVC 时，我遇到了一些很好的验证示例，其中业务规则与模型相关联，而 UI 仅显示错误集并标记与无效输入相关联的表单元素。我认为将这个逻辑放在一个地方而不是让每个表单都执行自己独特的验证是非常有意义的。

是否可以使用 ASP.NET Web 应用程序项目（webforms）以优雅的方式实现这种分离？我可以将验证规则保留在业务逻辑层中，并且我可以拥有执行验证并返回一组错误的方法。但是我想不出一种在 UI 端标记有问题的控件的好方法。

在 MVC 中，表单元素和模型通过属性名称隐式链接。ASP.NET 中的 UI 是否应该引用模型的唯一属性名称（作为 ID/名称或作为自定义属性）？UI 是否可以访问手动生成的控件名称到属性名称的映射？

我见过的所有关于 MVC 应该是什么以及如何使用的示例都使用类作为模型，类作为控制器，以及 HTML 模板作为视图。所有这些都由一个 index.php 脚本和 url 中的不同请求组成，以运行整个站点。

所以他们都像...

我理解为什么模型是由简单地获取和保存数据的类组成的（尽管我认为类并不总是必要的并且可以使用函数）。我理解为什么模板主要由 HTML 组成。但我不明白为什么控制器是一个类。我假设控制器是一个程序脚本（如 userprofile.php，它从模型中获取用户数据并将其发送到模板进行显示）。

另外，我想知道为什么我读过的每个教程都涉及 mod 重写，并使用带有请求的单个页面，如“index.php?user=1”或 index.php?news=3 来运行整个地点。像 user_profile.php?id=1 或 news.php?id=3 这样的单独页面有什么问题...

有人可以帮助我快速“教程”和一路上的解释。就像...如何使用 MVC 实现注册表单，什么会去哪里以及为什么？谢谢你

PS。还有哪些其他类型的设计模式

在我们的应用程序中，我们有许多具有数百个属性的模型对象。

对于模型上的每个属性：

我们必须在ViewModel上创建一个启用 INotifyPropertyChanged 的​​属性：

这意味着当我们的View发送Save事件时，我们必须将视图模型的所有这些值重新映射回模型：

随着模型不断变化，这变得乏味且耗时，我们必须将所有变化映射到 ViewModel 中。

过了一会儿，我们意识到将View 的 DataContext 直接连接到 Model 会更直接，这使我们能够将 XAML 元素直接绑定到 Model 对象属性，这样保存事件就可以简单地保存对象而无需任何映射任何东西。

我们在这次行动中失去的是：

• 通过在 ViewModel 属性设置器中UpdateSourceTrigger=PropertyChanged进行细粒度验证和操作的能力，我真的很喜欢：这个我们不再拥有，因为 XAML 中的任何更改都会简单地更改模型上的哑属性

• 能够（将来）创建模拟视图，以一种新颖的方式测试我们的视图模型的 UI 逻辑，例如“如果属性 SubscriptionKind 设置为“每年”，则 (1) 将折扣更改为 10%，(2) 运行“祝贺动画"，以及 (3) 使订单按钮更加突出。

这两种方法都有明显的优势，例如第一种方式“View-direct-to-Model”方法，尤其是与LINQ-to-SQL结合使用时，非常实用，可以让您快速生成有用的软件，并且只要您使用{Binding...}而不是x:Name您仍然可以“将您的视图交给 Blend Designer”。

另一方面，尽管 MVVM 要求您维护繁琐的 Model 到 ViewModel 的映射，但它为您提供了第一种方法所没有的强大的验证和测试优势。

您是如何在您的项目中结合这两种方法的优势的？

我已经看到了一些示例，其中 viewModel（在 Silverlight 应用程序中）位于 View 的 UserControl.Resources XAML 部分中。我读到使用 Blend，这是一个很好的地方（因为它提供了在 Blend 中查看示例数据的能力）。

但是，这是拥有 viewModel 的最佳位置吗？我读到“视图必须将服务推送到视图模型”。这是什么意思，还有什么地方可以或应该在哪里创建 ViewModel？

谢谢。京东。

我的域类和持久性逻辑（Hibernate）在一个名为模型的项目中。这个 jar 包含在我的所有应用程序中。
打包的 com.company.model 和 com.company.persistance

另一个 Utils.jar - 包含 DateTime、String、Thread 等通用辅助类。这再次包含在我的所有应用程序中。
打包的 com.company.utils

我有一个 CXF/Spring 应用程序，它公开了用于操作我的数据的服务。CRUD 功能，所有其他常用功能。对于任何设计的应用程序，这是进入我的数据库的“途径”。
打包 com.company.services 并在 Glassfish 应用服务器上运行

我有其他应用程序使用 Web 服务（注入 Spring）来操作我的数据。包括一个 Web 应用程序，它将使用 YUI 小部件和来自 Web 服务的 XML/JSON 以获得一个漂亮流畅的 UI。

我明白这不是一个真正的问题！我想我正在寻找其他人如何设计他们的软件的确认。如果我的架构很好，合乎逻辑！显然存在安全问题 - 我希望某些应用程序只允许访问服务 x。我稍后会解决这些问题。

在使用 ASP.Net MVC 之后，我开始考虑 Rails。我之前使用过 Rails，但有点生疏。ASP.Net MVC 教程建议使用存储库模式隐藏数据层实现。这允许更轻松的单元测试依赖注入，以及控制器与模型实现的良好解耦。

我记得 Rails 的控制器直接使用 Active Record 对象，以及使用可以轻松设置和拆除的测试数据库的单元测试。这解决了更换单元测试的需要，但在控制器中公开这么多 ActiveRecord 代码似乎仍然是个坏主意。

所以我的问题是，这里最新的最佳实践是什么？真实（非模拟）数据库是否仍用于单元测试？Rails 开发人员是直接调用 ActiveRecord 还是抽象？

问题：

我有一个遗留的 php 应用程序，它的编码没有特定的风格（一些 OO、函数库、一些模板、没有模板），我正在慢慢地重写、清理和添加它。

当我将模板引入系统时，很明显这会真正清理和简化代码，因为它提供了 html 和 php 之间的分离。我在工作中使用过 php MVC 框架，我非常喜欢体现 MVC 概念的关注点分离。但是，我不喜欢大型代码库引入的复杂性。我喜欢简单，当一个非常复杂的堆栈开始发挥作用时，我无法很好地处理无休止的嵌套调试。随着时间的推移，我越来越喜欢函数式风格，主要是因为对Clojure的调查。

我想有一个很好的方法来分离 php 中的关注点，最好不需要太多面向对象的代码，也不需要太多的堆栈，因为当我转向 php 5.3 及更高版本时，我想转向更具功能性的 php 风格。

制定解决方案：

• 没有大型/复杂的物体。
• 用于调试的短堆栈。
• 运行 php 5.2，直到它在 debian 中出现时才能升级到 5.3，所以功能风格会很好，但我可能暂时无法使用 5.3 的工具。
• 一个干净简单的主题，用于统一当前支离破碎的代码库。
• 对当前代码的影响越小越好。

单一职责原则和关注点分离有什么区别？

刚开始研究mvc，还不确定我是否掌握它。据我所知，它似乎是一个 3 层解决方案的实现，即模型对应于 DAL，控制器对应于业务逻辑层，视图作为表示层。

我在这里离基地很远吗？

我正在尝试测试我的控制器并保持关注点分离。

第一个问题是“谁能够执行哪个动作？”
我使用authlogic进行身份验证，使用be9 的 acl9进行授权。但这不重要，我所有的授权问题都在before_filter. 我正在before_filter通过与此类似的东西进行测试：

这个规范工作得很好！

现在，第二个问题是“这个动作是否做了它应该做的事情？”
这不涉及检查授权。最好/最干净的解决方案是before_filter一起跳过所有这些，只需执行以下操作：

无需担心必须先登录哪个角色的用户。现在我这样解决了：

如果我现在决定我的站点管理员不再有权访问索引操作，它不仅会破坏一个规范 - 即在这种情况下必须破坏的规范 - 而且还会破坏完全不相关的第二个规范。

我知道这基本上是一个小问题，但如果有人能想出一个（优雅的）解决方案，那就太好了！