UI层抽象

Question

我已成功处理抽象数据层和业务层。但最近一位同事提到了在UI和业务层之间抽象UI层。但是我无法理解它。我无法想象这个UI层与业务层的区别。我有足够的文章，并没有找到很多帮助。有人能告诉我一个简单的例子吗？

Answer 1

我已经阅读过关于MVC，MVP和Humble Dialog Box的内容。（我把头发拉了出来）。提到UI层的同事无法给我一个很好的例子，说明它与业务层的区别。当被问及他说这不是MVC / MVP时。因此，我以为我会问周围

Answer 2

这里有多种选择。

1. MVC

   您需要将View与模型和控制器分开。最容易想象为什么要这样做的方法是，如果您有相同的模型和控制器，您想要呈现不同的视图 - 网站视图，独立应用程序视图，Web服务视图，移动电话视图，您的单元测试视图等因此您不需要视图代码中的逻辑。即，在Java中，ActionListeners和其他GUI代码中没有模型操作 - 而是将其移动到控制器类中，而View处理程序只是执行输入验证，输出格式化以及与控制器类的对话。

   许多观点都是以视图为中心的方法编写的。你有你的GUI。有些事情会发生，你会对此做出反应并做一些事情，并在必要时更新GUI。因此，很容易将业务逻辑和模型紧密地绑定到视图中。

   基本上，您可以在业务逻辑中创建（一个）任何可以调用的接口，因此添加新视图很简单。这些接口提供了您需要调用的所有功能。然后，您可以将内部业务逻辑设为私有。

2. 数据收集网络表单（或一系列网络表单）

   您极不可能希望以与业务层中的数据模型相同的顺序收集信息。此外，您需要在多页表单中的页面之间保留。当您在第3页收集它们时，您会很快发现那些非空约束是PITA（因为它们会在第1页上关闭客户）。由于表单在重新排列后可能会发生变化，因此您最终会在很早的时候将业务逻辑从视图中分离出来，并概括您如何填充模型。还有很多其他的东西。

3. 从模型

   生成的界面

   您有一个可以更改的模型，或者确实可以显式或隐式地描述接口。因此，您可以从模型生成界面，而不是使用预先设计的表单和窗口等。这样，您必须非常一般地编写视图代码，因为您只能使用模型。从模型到UI的大量地图，反之亦然。然后你添加一些观察者，因为模型值在其他地方改变，这很有趣......：）

4. 还有别的......

Answer 3

我发现Jeremy Miller的Build Your Own CAB系列文章在过去非常有用。他描述了模型 - 视图 - 控制器模式系列的许多变体。这是一个很好的阅读。

Answer 4

简单来说，您的UI图层只关注自身，并与下一级协作（可能是您的业务层）。您的业​​务层和数据层（以及您拥有的任何其他层）不应该包含任何UI代码，因为它是UI层作业。

考虑网络浏览器的工作方式，浏览器是UI层，关注的是渲染页面而不是其他内容。当需要发生某些事情时，它会调用Web服务器（下一层）来执行此操作，然后呈现结果。

尝试使用Google搜索一些众所周知的UI模式：

MVC

MVP

The Humble Dialog Box

Answer 5

这是我的原则：如果你必须重写任何逻辑（除了操作表单控件），那么你还没有完全将UI层与其他层分开。就个人而言，我喜欢拥有一个服务层来保存我的业务规则，操纵域和数据映射对象，并且只与UI交换域对象。用户界面当时对数据映射或业务规则一无所知。

关于UI和我的服务层之间的单独“UI层”没有回答。也许这是为了保持HTML和代码分离（即ASP.Net的代码隐藏可能被视为UI层）。没有什么比改变/调试Web应用程序更糟糕的了，而不是在千兆不同功能中逐个构建标记时必须更改全局HTML设置。 HTML应该只是在HTML文件中，只需要最少的脚本就可以将它们与类相关联。