C# 如何在多层应用程序中处理视图

我正在做一个基本上有三层的项目：展示层、业务层和数据层。 每个层位于不同的项目中，所有层都使用另一个项目中定义的DTO。 查询数据库时，业务层和数据层返回DTO或DTO列表

到目前为止还不错，但现在我们必须查询视图，这些视图当然与现有DTO不匹配。到目前为止，我们所做的只是创建一个特殊的DTO、业务层和数据层类，以便将它们视为普通实体（减去插入、更新等）

但这似乎并不正确。为什么要像正常实体一样对待这些实体，而它们显然不是。DTO似乎是必要的，但为每个视图创建“业务逻辑”和数据层类似乎很困难。所以我想我创建了一个通用的业务和数据层类，它保存所有视图的逻辑/代码（我仍然需要为每个不同的视图创建一个DTO，也许我可以使用匿名类型）

你觉得我的想法怎么样？或者你会如何解决这个问题

编辑：9。2011年8月 对不起，帖子可能不清楚。

---

我所说的视图是指来自sql server的视图。

我建议不要在层之间使用DTO。我不认为这有什么好处，但如果你认为你有一些好处，我很乐意接受指导

其危害在于维护表达相同想法的多个并行层次结构（业务对象加上层之间的多个DTO）。这意味着需要维护更多的代码，并且出错的可能性更大

下面是我对应用程序分层的方法：

view <--- controller <--- service <--- + <--- model
                                       + <--- persistence

---

view我完全感受到了你的痛苦。事实上，在几乎每一个具有相当复杂度的非平凡项目中，您都会发现您必须在UI上向用户显示的内容重叠、聚合或只是业务实体数据的一个子集。我倾向于接受这一事实，并且更进一步——从逻辑和物理上将查询端与业务逻辑端分开。事实上，您只需要您的实体来进行实际业务操作并保持业务约束的有效性，这种情况何时发生？只有当有人更改数据时。因此，在显示数据时甚至不需要构建实体。
我喜欢的解决方案结构是：

用户打开视图->仅执行查询以获取特定的
视图->返回数据的数据就是模型（尽管您可以
也可以将其称为DTO，在这种情况下是相同的）

用户更改内容->控制器（或服务）从repo构建完整实体，
对实体执行业务逻辑操作->更改已完成
返回持久->结果

我想说的是，把读端和写端分开对待是可以的。为此，也可以使用不同的基础设施。当您开始以不同的方式对待它时，您将看到好处——例如，您可以根据UI上的需要定制查询。
您甚至可以使用不同的技术构建查询，例如使用LINQ或纯SQL查询，这对某些场景来说是最好的。我已经放弃了大多数这样的分层架构，因为它们管理所有转换都很困难，而且过于复杂。这是典型的宇航员建筑。我一直在使用以下方法：

ASP.NETMVC中窗体/视图的视图模型。这是一个重要的脱钩步骤。用户界面通常会单独演变为模型
没有服务层，而是将其替换为“命令处理程序”（变异操作）和“查找程序”（查询操作），分别表示小操作和查询（CQS-命令查询分离）
使用NHibernate和模型内的所有域逻辑进行模型持久化
任何外部服务都会与查找程序和命令处理程序进行对话
这导致了一个非常扁平的、可管理的、低耦合的体系结构，所有这些问题都消失了