如何处理多层应用程序中的视图
我正在开发一个项目，该项目基本上分为三个层：表示层、业务层和数据层。 每个层都位于不同的项目中，并且所有层都使用另一个项目中定义的 DTO。 业务层和数据层在查询数据库时返回DTO或DTO列表。
到目前为止一切顺利，但现在我们必须查询视图，而这些视图当然与现有的 DTO 不匹配。到目前为止，我们所做的只是创建一个特殊的 DTO、业务层和数据层类，以便将它们视为普通实体（减去插入、更新等），
但这似乎不正确。当它们显然不是时，为什么要像正常实体一样对待它们呢？好吧，DTO 似乎是必要的，但为每个视图创建“业务逻辑”和数据层类似乎相当尴尬。所以我想我创建一个通用的业务和数据层类，它保存所有视图的逻辑/代码（我仍然必须为每个不同的视图创建一个 DTO，也许我可以使用匿名类型）
您对我的想法有何看法或你会如何解决这个问题？
编辑：2011 年 8 月 9 日 抱歉，帖子可能表述不清楚。 我所说的视图是指来自 sql 服务器的视图。
I'm working on a project which has basically three layers: Presentation, business and data.
Each layer is on a different project and all layers use DTO's defined in another project.
business layer and data layer return DTO's or Lists of DTOs when querying the database.
So far so good, but now we have to query views and those views of course do not match an existant DTO. What we have done until now is just create a special DTO, business- and data-layer classes so they were treated like normal entities (minus insert, update etc.)
But it does not seem correct. Why should the be treated like normal entities when they are clearly not. Well the DTO seems necessary, but creating "business logic" and a datalayer-class for every view seems rather akward. So I thought I create one generic business- and datalayer class which holds the logic/code for all views (I still would have to create a DTO for every different view, perhaps I could use anonymous types)
What do you think about me idea or how would you solve this issue?
EDIT: 9. August 2011
Sorry, the post may have been unclear.
By views I meant Views from a sql-server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我完全感受到你的痛苦。事实上，在几乎每个具有相当复杂性的重要项目中，您都会遇到必须在 UI 上向用户显示的内容重叠、聚合或只是业务实体数据的子集的情况。我倾向于解决这个问题的方法是接受这个事实并进一步 - 在逻辑上和物理上将查询端与业务逻辑端分开。事实上，您仅需要实体来进行实际业务运营并保持业务约束有效，这种情况何时发生？仅当有人更改数据时。因此，在显示数据时甚至不需要构建实体。
我喜欢构建解决方案的方式是：
我想说的是，将读端与写端分开对待是可以的。为此拥有不同的基础设施也是可以的。当您开始以不同的方式对待它时，您将看到好处 - 例如，您可以根据 UI 上的需要定制查询。
您甚至可以达到这样的程度：您的基础设施允许使用不同的技术构建查询，例如使用 LINQ 或纯 SQL 查询 - 这对于某些场景来说是最好的。
I feel your pain completely. The fact is that in almost every non trivial project with decent complexity you will get to the point where the things you have to show to the users on UI overlap, aggregate or are simply a subset of data of business entities. The way I tend to approach this is to accept this fact and go even further - separate the query side from the business logic side both logically and physically. The fact is that you need your entities only for actual business operations and keeping the business constraints valid, and when does this happen? Only when someone changes the data. So there is no need to even build entities when you display the data.
The way I like to structure the solutions is:
What I want to say is, it is ok to treat your read side separately from write side. It is ok to have different infrastructure for this as well. When you start to treat it differently, you will see the benefits - for example you can tailor you queries to what you need on UI.
You can even get to the point where your infrastructure will allow to build your queries with different techniques, for example using LINQ or plain SQL queries - what is best for certain scenarios.
我建议不要在层之间使用 DTO。我不相信有任何好处，但如果你认为你有一些好处，我会很乐意接受指导。
危害在于维护表达相同想法的多个并行层次结构（业务对象加上层之间的多个 DTO）。这意味着需要维护更多的代码，并且出现错误的可能性更大。
以下是我对应用程序进行分层的方式：
这种设计将视图与服务分离；您可以以不同的视图重用服务。服务方法实现用例，根据业务规则、自己的工作单元和事务验证输入，并与模型和持久性对象协作来满足请求。
控制器和视图紧密耦合；改变视图，改变控制器。视图除了呈现控制器提供的数据之外什么也不做。控制器负责验证、绑定、选择适当的服务、使响应数据可用以及路由到下一个视图。
诸如日志记录、事务、安全性等横切关注点应用在适当的层（通常是服务）。
服务和持久性应该是基于接口的。
I would advise against using DTOs between layers. I'm not convinced that there's any benefit, but I'll be happy to take instruction if you think you have some.
The harm comes in maintaining multiple parallel hierarchies that express the same idea (business objects plus multiple DTOs between layers). It means lots more code to maintain and greater possibility of errors.
Here's how I'd layer applications:
This design decouples views from services; you can reuse services with different views. The service methods implement use cases, validate inputs according to business rules, own units of work and transactions, and collaborate with model and persistence objects to fulfill requests.
Controller and view are tightly coupled; change the view, change the controller. The view does nothing other than render data provided by the controller. The controller is responsible for validation, binding, choosing the appropriate services, making response data available, and routing to the next view.
Cross cutting concerns such as logging, transactions, security, etc. are applied at the appropriate layer (usually the services).
Services and persistence should be interface-based.
我已经放弃了大多数像这样的分层架构，因为它们管理所有转换很痛苦并且过于复杂。这是典型的宇航员建筑。我一直在使用以下内容：
这导致了一个非常扁平、低耦合的可管理架构，所有这些问题都消失了。
I've dropped most layered architectures like this as they are a pain to manage all the transformations and are over-complicated. It's typical astronaut architecture. I've been using the following:
This leads to a very flat manageable architecture with low coupling and all these problems go away.