我应该从UI层返回到业务层？

Question

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

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

非常感谢

Answer 1

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

首先，这样可以使UI层更清晰，更简单，使其能够显示数据，而不是遍历对象结构，检查和解释空值等。

这也为业务层提供了对这些字符串值进行验证的机会，如果值无效，则返回输入的值。例如，当您的服务器必须处理日期字段中的无效日期时，这可以节省编码挫折。识别无效值的业务层可以完全按照收到的方式返回它们以及正确的错误消息。如果您处理的只是业务/域对象，那么输入的某些值可能并不总是适合用于保存它们的对象。

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

Answer 2

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

对于网络应用程序，这非常方便，因为您不需要向客户端来回发送过多的数据。

Answer 3

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

在保存数据时，您可以将这些对象作为BL和/或DAL图层上的参数传递。如果在UI控件上绑定了当前对象，或者创建该对象的新实例并设置更改，则可以将当前对象传回。

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

Answer 4

我发现最简单的解决方案是将View Model对象从UI传递到Business层，原因有两个。最明显的是验证应该在业务层中进行，因此在UI中创建业务对象会破坏MVC的原则。

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