我已经成功地处理了抽象数据层和业务层。但是最近一位同事提到了在 UI 和业务层之间抽象 UI 层。但是我无法理解它。我无法想象这个 UI 层与业务层有何不同。我已经看够了文章，似乎没有找到太多帮助。有人可以告诉我一个简单的例子吗？
问问题
4441 次
4 回答
1
这里有多种选择。
MVC
您需要将视图与模型和控制器分开。想像为什么要这样做的最简单方法是，如果你有相同的模型和控制器，你想呈现不同的视图——网站视图、独立应用程序视图、网络服务视图、手机视图，您的单元测试视图等。因此，您的视图代码中不需要任何逻辑。即，在Java 中，您的ActionListeners 和其他GUI 代码中没有模型操作——相反，您将其移到控制器类中，视图处理程序只进行输入验证、输出格式化和与控制器类对话。
许多视图是从以视图为中心的方法编写的。你有你的图形用户界面。发生了一些事情，你对此做出反应并做一些事情，并根据需要更新 GUI。因此，很容易将您的业务逻辑和模型紧密地绑定到视图中。
基本上，您在业务逻辑中创建（一个）接口，任何东西都可以调用，因此添加新视图很简单。这些接口提供了您需要调用的所有功能。然后，您可以将内部业务逻辑设为私有。
数据收集网络表单（或一系列网络表单）
您不太可能希望以与业务层中的数据模型相同的顺序收集信息。此外，您将需要在多页表单中的页面之间保持不变。当您在第 3 页收集这些非空约束时，您会很快发现它们是一个 PITA（因为它们在第 1 页上让客户望而却步）。因为表单在重新排列时可能会发生变化，因此您最终会很早就将业务逻辑与视图分离，并概括您如何填充模型。还有很多其他的东西。
从模型生成的接口
您有一个可以更改的模型，或者确实可以显式或隐式地描述接口。因此，您可以从模型生成界面，而不是使用预先设计的表单和窗口等。这样，您必须非常通用地对视图代码进行编程，因为您将只能使用模型。从模型到 UI 的大量地图，反之亦然。然后你添加一些观察者，因为模型值在其他地方发生了变化，这很有趣...... :)
别的...
于 2009-01-08T15:58:18.163 回答
1
我发现 Jeremy Miller 的Build Your Own CAB系列文章过去提供了非常丰富的信息。他描述了模型-视图-控制器系列模式的许多变体。这是一本极好的读物。
于 2009-01-08T16:27:10.757 回答
0
这是我的原则：如果您必须重新编写任何逻辑（除了操作表单控件），那么您还没有将 UI 层与其他层完全分开。就个人而言，我喜欢有一个服务层来保存我的业务规则，操作域和数据映射对象，并且只与 UI 交换域对象。UI 那时对数据映射或业务规则一无所知。
这并没有回答关于 UI 和我的服务层之间单独的“UI 层”。也许这是为了将 HTML 和代码分开（即 ASP.Net 的代码背后可能被视为 UI 层）。当标记在上千个不同的函数中零散构建时，没有什么比更改全局 HTML 设置更糟糕的了（在更改/调试 Web 应用程序时）。HTML 应该只是在 HTML 文件中，并且将它们与类相关联所需的脚本数量最少。
于 2009-01-08T20:12:55.123 回答
0
简而言之，您的 UI 层只关注 UI 并与下一层（可能是您的业务层）协作。您的业务层和数据层（以及您拥有的任何其他层）中不应包含任何 UI 代码，因为这是 UI 层的工作。
想想 Web 浏览器的工作方式，浏览器就是 UI 层，它只关心渲染你的页面，而不是别的。当需要发生某些事情时，它会调用 Web 服务器（下一层）来执行此操作，然后呈现结果。
尝试在谷歌上搜索一些众所周知的 UI 模式：
于 2009-01-08T15:49:00.633 回答