我应该从 UI 层返回到业务层什么？答案

【问题标题】：What should I return from the UI layer to the business layer?我应该从 UI 层返回到业务层什么？
【发布时间】：2011-01-18 16:41:22
【问题描述】：

我正在编写一个 ASP.NET 应用程序，它有一个 UI 层、业务逻辑层和数据访问层。从我的数据层，我将业务对象返回到业务逻辑层，并将它们传递给 UI 层。但是，当我想使用来自 UI 层的数据执行保存/插入时，我不确定该怎么做。

我应该在 UI 层创建业务对象并传递给业务层还是应该在业务层中创建它？

非常感谢

【问题讨论】：

标签： asp.net oop

【解决方案1】：

我同意 crunchdog 的观点——对于除了最琐碎的 Web 应用程序之外的所有应用程序，您都应该拥有专门用于 UI/视图层的扁平化形式的业务对象。有时这被称为 View Model 类，通常只包含几个字符串属性，UI 层可以直接从中获取和放入，而无需担心验证。（见asp.net mvc）

一方面，这使 UI 层更干净、更简单，让它努力显示数据，而不是遍历对象结构、检查和解释空值等。

这也使业务层有机会对这些字符串值进行验证，如果输入无效，则返回输入的值。例如，当您的服务器必须处理日期字段中的无效日期时，这可以节省编码挫败感。识别出无效值的业务层可以将它们与正确的错误消息一起返回。如果您处理的只是业务/域对象，那么输入的某些值可能并不总是适合保存它们的对象。

指定一个类来在业务/域对象和 UI 对象/视图模型之间来回映射值也很有帮助。这有助于保持业务层关注点清晰分离。

【讨论】：

【解决方案2】：

我发现拥有模拟“真实”业务对象的 UI 层对象会更好。这些模型对象不需要具有“真实”业务对象所具有的所有信息（关联等）。然后业务层必须负责从业务对象转换为业务对象。

对于 Web 应用程序来说，这特别方便，因为您不需要向客户端来回发送过多的数据。

【讨论】：

【解决方案3】：

如果您不希望对业务对象进行过多编码，那么您在检索数据时做了正确的事情（其中您将相同的业务对象从 DAL 返回到 BL 再到 UI）。

在保存数据时，您可以将这些对象作为参数传递到您的 BL 和\或 DAL 层。如果您将当前对象绑定到您的 UI 控件上，您可以将其传回，也可以创建该对象的新实例并完成更改。

然后在 DAL 层读取对象并将更改保存回数据库。

【讨论】：

【解决方案4】：

我发现最简单的解决方案是让一个视图模型对象从 UI 传递到业务层，原因有几个。最明显的是验证应该发生在业务层，因此在 UI 中创建业务对象违反了 MVC 的原则。

更重要的是，如果用户输入了无效数据，业务对象可能（正确地）无法接受该数据。但是，您不想丢弃用户输入的数据，因此无需验证的 View Model 对象为您提供了一种存储和传递用户输入数据的方法，无论它是否有效。

【讨论】：