在 ntier 应用程序中传递数据
如何将数据传递到 n 层应用程序中的层？ 我已经制定了 3 种不同的方法。
A) 通用 .net 对象通用数据表、哈希表、通用数据集、字符串、整数等... 然后使用数据集填充发送到 UI 层的业务对象。
替代文本 http://img11.imageshack.us/img11/460/generic.png
http://dabbleboard.com/draw?b=eiu165&i =26&c=54eef6f1ac01f03c85919518f4a24e798e57e133
Pro- 不需要额外的层 Con- 必须使用业务层中的通用数据集和表格
B) 使用其他层将引用的实体层。 该层将包含强类型数据集或普通旧 C 对象。 这些对象主要是容器数据和很少的逻辑。 这些将与发送到 UI 层的对象相同。
替代文本 http://img8.imageshack.us/img8/6454/entities.png
http://dabbleboard.com/draw?b=eiu165&i =6&c=d0c2b346894a96b12bd3867f630e474a2af098fa
Pro- 在所有层中使用相同的类 Con-添加对entities.dll的引用到所有层
C) 使用数据访问层中定义的数据传输对象（仅容器对象）。 然后使用这些对象来填充发送到 UI 层的业务对象。
替代文本 http://img43.imageshack.us/img43/1236/transferp.png
http://dabbleboard.com/draw?b=eiu165&i =27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b
Pro- 业务层不必使用泛型类 使用两种类型的对象，您必须将业务对象与传输对象结合在一起
我们在工作中进行了一次讨论，希望了解社区的想法。 我还添加了一个指向仪表板的链接。 请复制并创建而不是编辑。
谢谢
How do you pass data to layers in an n-tier application? I have mapped out 3 different methods.
A)
generic .net objects generic data tables, Hashtables, generic datasets, strings, ints etc...
then using the datasets to fill your business objects which get sent to the UI layer.
alt text http://img11.imageshack.us/img11/460/generic.png
http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133
Pro- No extra layers needed
Con- Have to work with Generic datasets and tables in the business layer
B)
using an entities layer that the other layers would reference. This layer would contain either strongly typed datasets or Plain Old C Objects. The objects would be mostly container data and very little logic. these would be the same objects sent to the UI layer.
alt text http://img8.imageshack.us/img8/6454/entities.png
http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa
Pro- working with the same classes in all layers
Con- adding a reference to entities.dll to all layers
C)
use data transfer objects (conatiner objects only) defined in the DataAccess Layer. then using those objects to fill business objects which get sent to the UI layer.
alt text http://img43.imageshack.us/img43/1236/transferp.png
http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b
Pro- the business layer would not have to work with generic classes
Con- working with two types of objects and you would have to hydrate the business objects with the transfer objects
We had a discussion at work and wanted to see what the community thought. I also added a link to the dabbleboard. please copy and create instead of editing.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您使用分层方法，这意味着所有层（本质上）都在同一进程空间中执行，因此没有编组/序列化，我会使用方法 B。创建一个单独的模块对于您的程序的所有方面所依赖的实体，以及与之相关的实体。
但是，如果您使用的是分层方法，正如您的标题所示，这意味着存在跨越的流程和/或网络边界，我建议您采用方法 C。实际上传递实例时，您传递的是副本，因此耦合到同一对象所获得的任何好处（例如 MVC 方法的可观察选项）无论如何都会丢失。 在每个层定义数据 API 比尝试到处使用相同的类更好。
If you're using a layered approach, meaning all layers are (essentially) executing in the same process space and there is therefore no marshalling/serialization, I'd go with approach B. Create a separate module for your entities upon which all aspects of your program depend, and couple to that.
If, however, you're using a tiered approach as your title suggests, meaning there are process and/or network boundaries that are crossed, I'd suggest you go with approach C. You're not really passing instances around, you're passing copies, so any benefits you get to coupling to the same object, like observable options for, say, an MVC approach, are lost anyway. Better to define data APIs at every tier level than to try to use the same class all around.
很好的问题——一如既往，答案必须是“视情况而定”。
关于应用程序的类型，以及是否确实需要拥有业务对象（实体），而不是传输对象（即更多地对应于数据库实体的简化业务对象）。
传统上，我认为您总是需要通用数据集（或数据表），纯粹是出于性能原因。 每当需要使用、显示或操作更大的集合时，实例化大量业务对象的传统严格面向对象方法就会失败。
然而，自从我开始使用 Linq to SQL 以来，我的范例发生了变化。 根本不再需要这样做，因为 Linq 模型可以是一切 - 业务对象、传输对象和通用数据集。 我还没有探索这在真正的大型应用程序中效果如何，以及是否需要将前端代码与 Linq 模型隔离。 我和同事们讨论过这个问题，但都没有真正找到答案。
Great question - as always, the answer has to be "it depends".
On the type of application, and whether there is really a need to have business objects (Entities), as opposed to transfer objects (ie dumbed-down business objects that correspond more to database entities).
Traditionally, I would have argued that you always have a need for generic data sets (or data tables), purely for performance reasons. Whenever there is a need to work with, display, or manipulate larger sets, the traditional strict OO way of instantiating large numbers of business objects failed.
However, since I started to work with Linq to SQL, my paradigms have changed. There is no longer a need for this at all, since the Linq model can be everything - business objects, transfer objects, and generic datasets. I have not explored yet how well this works in really large applications, and whether there should be a need to isolate front-end code from the Linq model. I have had discussions about it with colleagues, without really finding an answer either way.
我喜欢选项 C，但它也让我犹豫了两个原因：
I like option C but it also gives me pause for two reasons:
我假设所有 3 层都存在于同一个应用程序中。 在java中，我至少使用Hibernate进行数据访问，并在所有层中使用这些数据bean。 （选项 B）能够在层中重用实体是有意义的。
I am assuming all 3 layers exists within the same app. In java atleast I've used Hibernate for Data access and used those data beans in all layers. (option B) It makes sense to be able to reuse your entities in your layers.