如何处理多层应用程序中的视图 [英] How to handle views in a multilayer-application

问题描述

我正在从事一个基本上具有三层的项目:演示文稿、业务和数据.每个层都在不同的项目中，所有层都使用另一个项目中定义的 DTO.业务层和数据层在查询数据库时返回 DTO 或 DTO 列表.

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.

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

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.)

但这似乎不正确.当它们显然不是时，为什么要像正常实体一样对待它们.好吧，DTO 似乎是必要的，但是为每个视图创建业务逻辑"和数据层类似乎相当尴尬.所以我想我创建了一个通用的业务和数据层类来保存所有视图的逻辑/代码(我仍然必须为每个不同的视图创建一个 DTO，也许我可以使用匿名类型)

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?

2011 年 8 月 9 日抱歉，帖子可能不清楚.我所说的视图是指来自 sql-server 的视图.

9. August 2011 Sorry, the post may have been unclear. By views I meant Views from a sql-server.

推荐答案

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

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:

用户打开视图 ->执行查询只是为了获取特定的视图的数据 ->返回的数据是模型(虽然你可以也称它为 DTO，在这种情况下，它是一样的)

User opens the view -> Query is performed only to get the specific data for the view -> Returned data is the model (although you could call it a DTO as well, in this case it's the same thing)

用户改变了一些东西 ->控制器(或服务)从 repo 构建完整的实体，对实体执行业务逻辑操作 ->变化是坚持 ->结果返回

User changes something -> Controller (or service) builds the full entity from repo, business logic action is performed on the entity -> changes are persisted -> result is returned

我想说的是，把你的读端和写端分开处理是可以的.也可以为此拥有不同的基础设施.当您开始以不同的方式对待它时，您会看到好处 - 例如，您可以根据 UI 需要定制查询.您甚至可以达到您的基础架构允许使用不同技术构建查询的程度，例如使用 LINQ 或纯 SQL 查询 - 哪种方式最适合某些场景.

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.

这篇关于如何处理多层应用程序中的视图的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！