我应该从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到BL的相同业务对象返回到UI）。

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

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

Answer 4

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

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