3 层 Web 服务启用架构
在网上阅读了大量有关最佳实践应用程序设计和模式的文章后，我仍然无法将所有信息合并在一起并映射到我的实际应用程序上......
我想要一个 3 层应用程序：
- UI 层：
托管在 ASP.net 中的 silverlight 应用程序 - Web 应用程序 - BusinessLogicLayer：
WCF 服务/.NET RIA-在不同服务器上运行的服务 - DataAccessLayer：使用像 nHibernate 或 Linq2Entities 这样的 ORM
问题是，我不知道在哪里放置我的业务对象，以及在哪里填充数据。
是否应该有另一个层，包含我的所有业务对象，以便它们可以在所有其他 3 层中使用？
或者我应该将它们放入我的 BLL 中并在 DAL 中调用 nHibernate-Methods - 但这样我就会在 BLL 和 DAL 之间产生循环依赖？ 如果我在 DAL 中引入“DataAccessObjects”并将所有属性复制到 BLL 中的 BusinessObjects 中，这不是“过度架构”吗？
任何帮助表示赞赏！
此致， 丹尼尔·朗
After reading tons of articles over the net about best-practise application-design and pattern I still cannot merge all the information together and map on my real-word-application...
I would like to have a 3-tiered application:
- UI-Layer:
A silverlight-application hosted within an ASP.net - Webapp - BusinessLogicLayer:
WCF-Services / .NET RIA-Services running on a different Server - DataAccessLayer:Using an ORM like nHibernate oder Linq2Entities
The problem is, I don't know where to put my business objects, and where to fill them with data.
Should there be an another layer, containing all my business objects, so they could be used in all other 3 layers?
Or should I place them into my BLL and call nHibernate-Methods in the DAL - but then I would have a circular dependency between BLL and DAL?
Isn't it "over-architectured" if I introduce "DataAccessObjects" inside the DAL and just copy all the properties into the BusinessObjects in the BLL?
Any help appreciated!
Best regards,
Daniel Lang
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
业务对象位于业务层。这些对象由 UI 层使用，并调用数据层的方法来填充自身。
一般来说，一层中的对象只调用自己层或下一层的方法。
动机之一是能够在不改变其他层的情况下替换其中一层。例如，可能有不同的方式来呈现 UI，它可以使用业务层的相同方法。或者，也许可以更改数据库，只要新数据层包含与旧数据层相同的方法即可。
The business objects go in the Business layer. These objects are used by the UI layer, and call methods from the Data layer to populate themselves.
In general, objects in a layer only call methods in their own layer, or the one just below.
One of the motivations is to be able to replace one of the layers without changing the others. For example, there could be a different way to present the UI, which could use the same methods from the business layer. Or, perhaps the database could be changed, as long as the new data layer contains the same methods as the old one.
好吧，因为您使用的是 WCF，所以您应该有一个仅包含接口和数据类的“契约”。这些课程应该可供其他人使用。其中不应包含任何逻辑。
Well, because you're using WCF, you should have a "contract" that only contains interfaces and data classes. Those classes should be available to everyone else. No logic should be contained inside it.
好吧，在回顾整个问题之后，我认为“最佳”解决方案是使用 DependencyInjection 或 IversionOfControl 用 DAL 中的数据填充业务对象。
Well, after reviewing the whole problem, I think the "best" solution is to use DependencyInjection or IversionOfControl to fill the business-objects with data in the DAL.
业务对象位于公共层中，
我通常创建一个项目，它们包含业务对象、枚举以及服务器和客户端之间常见的任何内容。
该项目被所有层引用。它不能引用任何其他项目，否则这将创建循环引用。
the business objects go in a Common layer,
I usually create a project and they contain, business objects, enums and whatever is common between server and client.
this project is referenced by all layers. It cant have references to any other project otherwise this would create a circular reference.