我正在开展一个基本上有三层的项目：演示，业务和数据。 每个图层都在不同的项目中，所有图层都使用在另一个项目中定义的DTO。 在查询数据库时，业务层和数据层返回DTO或DTO列表。
到目前为止一切顺利，但现在我们必须查询视图，而这些视图当然与现有的DTO不匹配。到目前为止我们所做的只是创建一个特殊的DTO，业务和数据层类，以便将它们视为普通实体（减去插入，更新等）。
但这似乎不正确。当它们显然不是时，为什么要像普通实体一样对待它们。好吧，DTO似乎是必要的，但为每个视图创建“业务逻辑”和数据层类似乎相当尴尬。所以我想我创建了一个通用的业务和数据层类，它包含所有视图的逻辑/代码（我仍然需要为每个不同的视图创建一个DTO，也许我可以使用匿名类型）
您如何看待我的想法或如何解决这个问题？
编辑：2011年8月9日 对不起，该帖子可能不清楚。 通过视图我的意思是来自sql-server。
答案 0 :(得分：1)
我完全感受到你的痛苦。事实上，在几乎所有具有相当复杂性的非平凡项目中，您将达到这样的程度，即您必须在UI上向用户显示的内容重叠，聚合或仅仅是业务实体数据的子集。我倾向于接近这一点的方法是接受这个事实并进一步 - 在逻辑上和物理上将查询方与业务逻辑方分开。事实是，您只需要实体业务运营的实体，并保持业务约束有效，何时会发生这种情况？只有当有人更改数据时因此，在显示数据时甚至无需构建实体。 我喜欢构建解决方案的方式是：
用户打开视图 - ＆gt;仅执行查询以获取特定的查询 视图数据 - ＆gt;返回的数据是模型（尽管你可以 称它为DTO，在这种情况下也是同样的事情）
用户更改内容 - ＆gt;控制器（或服务）从repo构建完整的实体， 在实体上执行业务逻辑操作 - ＆gt;变化是 坚持 - ＆gt;返回结果
我想说的是，可以将您的阅读方与写方分开处理。也可以为此设置不同的基础设施。当您开始以不同方式对待它时，您将看到其中的好处 - 例如，您可以根据UI的需要定制查询。 您甚至可以使用基础结构允许使用不同技术构建查询，例如使用LINQ或纯SQL查询 - 这对于某些情况最有效。
答案 1 :(得分：0)
我建议不要在图层之间使用DTO。我不相信有任何好处，但如果你认为你有一些好处，我会很乐意接受教育。
损害在于维护表达相同想法的多个并行层次结构（业务对象加层之间的多个DTO）。这意味着需要维护更多代码并且错误的可能性更大。
以下是我如何分层应用程序：
view <--- controller <--- service <--- + <--- model
+ <--- persistence
此设计将视图与服务分离;您可以重用具有不同视图的服务。服务方法实现用例，根据业务规则验证输入，自己的工作单元和事务，并与模型和持久性对象协作以满足请求。
控制器和视图紧密耦合;更改视图，更改控制器。视图除了渲染控制器提供的数据外，什么都不做。控制器负责验证，绑定，选择适当的服务，提供响应数据，以及路由到下一个视图。
在适当的层（通常是服务）应用交叉问题，例如日志记录，交易，安全性等。
服务和持久性应该基于接口。
答案 2 :(得分：0)
我已经删除了大多数这样的分层架构，因为它们很难管理所有转换并且过于复杂。这是典型的宇航员建筑。我一直在使用以下内容：
这导致了一个非常扁平的可管理架构，耦合度低，所有这些问题都消失了。