从表示层引用业务对象的最佳方式..？
我想开发一个企业应用程序，其中包括 WindowsForms 表示层、用于业务逻辑和数据访问的中间层组件以及 MsSQL Server 数据库。中间层组件应包含一些业务对象，并将使用 .NET Remoting 从表示层调用。从表示层引用这些业务对象的最佳方式（以及原因）是什么？
- A) 创建类库项目，实现业务对象。从表示层和中间层引用该项目。
- B) 创建定义业务对象的接口库项目。创建实现接口的类库项目。参考中间层的类库项目。从表示层参考接口库项目。
- C) 为中间层和表示层创建单独的类库项目。从表示层引用相应的项目。
I want to develop an enterprise app that includes a WindowsForms presentation layer, middle-tier components for business logic and data access, and a MsSQL Server database. Middle-tier components should contain some business objects and will be called from presentation layer using .NET Remoting. Whitch is the best way (and why) to reference these business objects from presentation layer?
- A) Create class library project, implementing business objects. Reference this project from presentation layer and middle-tier layer.
- B) Create interface library project defining business objects. Create class library project implementing interfaces. Reference class library project from middle-tier layer. Reference interface library project from presentation layer.
- C) Create separate class library projects for middle-tier and presentation layer. Reference corresponding project from presentation layer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个问题可能没有明确的答案，这取决于你在做什么。
A 通常就足够好了。对于小型“单一应用程序”项目，没有任何理由不能直接从 UI 层和 BL 层引用业务对象库。它当然是最简单的，有时简单就是最好的。
B 可能是“最好的”，您将抽象出实际的实现，以便将来可以在不违反合同的情况下进行更改，并且如果有接口，单元测试会更容易。这样做的另一个好处是，以后如果你觉得有必要的话，从 B 切换到 C 也不会太困难。
C 可能有点过分了。也就是说，在较大的项目中您可能会发现它是必要的。我曾开发过大型客户端-服务器 n 层应用程序，这些应用程序具有多达三个独立的数据对象集。 DA层中使用的一组，用于映射并存储在数据库中。第二组位于业务逻辑层和网络层，用于处理和通过网络传递，第三组位于客户端，用于绑定到 UI。由于抽象优势，也值得考虑使用 C 接口。
总而言之，在不确切知道您的应用程序域或范围的情况下 - B 是一个很好的起点。
There's probably no clear cut and definite answer to this, it depends on what you are doing.
A will often be good enough in many cases. For small 'single app' projects there isn't really any reason why you can't just reference the business object library directly from both UI and BL layers. It's certainly the simplest, and sometimes simplicity is best.
B is probably the "best", You'll be abstracting your actual implementations away so future changes are possible without breaking contracts, and unit testing is easier if you have interfaces. The other advantage of this is that you won't find it too difficult to switch from B to C in the future if you find it necessary.
C is probably overkill in most cases. That said, on larger projects you may find it necessary. I've worked on large client-server n-tier applications that have had as many as three independent sets of data objects. One set used in the DA layer to map and store in the database. A second set in the business logic and network layers for processing and passing over the network, and the third set in the client for binding to the UI. It's worth considering using interfaces for C as well because of the abstraction advantages.
All in all, without knowing exactly your application domain or scope - B is a good starting point.
我发现这三种方法都很有效。
有时最好是从 A 开始，然后随着复杂性的增加移动到 B，然后是 C。
在简单的项目中，“业务对象”可以包含在与表示层和持久层相同的项目中 - 尽管这可能看起来有些异端，使用不同的命名空间定义对象可以在“层”之间提供足够的分离。
您可能需要重新考虑使用 .NET Remoting - WCF 是迄今为止更好的技术并且更易于使用。
I've seen all three approaches work well.
What can sometimes be good is to start with A, then as the complexity increases move to B, then C.
In simple projects the "business objects" can be included in the same project as the presentation and persistence tiers - although it may seem heresy, defining the objects using different namespaces can provide enough separation between the "layers".
You may want to reconsider use of .NET Remoting - WCF is by far a better technology and much easier to use.