业务层设计
我们目前正在改进应用程序的架构和设计。我们刚刚完成了数据访问层的设计，它是通用的，因为它使用 XML 和反射来保存数据。
不管怎样，现在我们正处于设计业务层的阶段。我们阅读了一些与企业架构和设计相关的书籍，因此我们发现可以应用于业务层的模式很少。表模式和域模型是此类模式的示例。我们还发现了领域驱动设计。
早些时候，我们决定针对表对象构建实体。但我们发现，在 DDD 中，实体和值对象是有区别的。对于那些经历过这种设计的人来说。请指导我有关模式、实践和示例的内容。
先感谢您！另外，如果您没有明白我的任何观点，请随时讨论。
We are currently revamping our architecture and design of application. We have just completed design of Data Access Layer which is generic in the sense that it works using XML and reflection to persist data.
Any ways now we are in the phase of designing business layer. We have read some books related to Enterprise Architecture and Design so we have found that there are few patterns that can be applied on business layer. Table Pattern and Domain Model are example of such patterns. Also we have found Domain Driven Design as well.
Earlier we decided to build Entities against table objects. But we found that there is difference in Entities and Value Objects when it comes to DDD. For those of you who have gone through such design. Please guide me related to pattern, practice and sample.
Thank you in advance! Also please feel free to discuss if you didn't get any point of mine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
@Adil，这不是您原来问题的答案，但我建议您修改您自己的数据访问层的决定。您注意到您想要转到 NHibernate：现在就这样做。
在我看来，除非有一些非常具体的限制，否则编写 ORM 是浪费时间。有很多选择，我们已经投入了数百个小时的努力。利用它！ LINQ2SQL、实体框架、NHibernate、Subsonic、LLBLGen 都很好，而且还有更多。
另请注意，如果您自己开发，则无需付出很大的努力就无法使用 LINQ 的优点。
就分层而言，尽量不要发疯：控制层数，集中精力在它们之间构建一个有价值的接口，以防止抽象泄漏。
我见过许多非常“模式化”、分层精美的项目，这些项目在使用中最终导致到处都是逻辑，并且持久性抽象到处泄漏。保持简单！
@Adil, this is not an answer to your original question, but I would advise you to revise your decision to roll your own data access layer. You note that you'd like to go to NHibernate: just do it now.
IMO, writing an ORM is a waste of time unless you have some very specific restrictions. There are a wealth of options out there, with hundreds of hours of effort poured into them already. Leverage it! LINQ2SQL, Entity framework, NHibernate, Subsonic, LLBLGen are all good, and there are more out there.
Note too that if you roll your own you won't get to use the goodness that is LINQ without a lot of effort.
As far as layering goes, try not to go nuts: keep the number of layers in check and concentrate instead on building a worthwhile interface between them to guard against your abstractions leaking.
I've seen a number of very "patterned", beautifully layered projects that in use end up with logic everywhere and persistence abstractions leaked all over the place. Keep it simple!
CSLA.NET 作为业务层的基础，效果非常好。
CSLA.NET works pretty well as a base for the business layer.
@Adil，
我不是很有经验的用户，无论如何，这就是我正在使用的模型（也使用 NHibernate）。
GUI - 包含所有 Web 表单等
BLL - 负责创建新对象实例的目录
DAL - 负责与 NHibernate 交互的类实现的地方。 NHibernate 映射文件位于此处。
Model - 类库，用于由 BLL 和 DAL 之间进行数据传输的对象。
使用不同的图案。例如，BLL 和 DAL 有一个允许访问接口的 Factory 类。目录是单例类。所有目录都可以使用代表我的业务逻辑顶级对象的主 Singleton 类进行访问（例如“Enterprise”=>“Enterprise.PeopleCatalog”。
无论如何，希望它有所帮助......
@AngryHacker，感谢您的提示，您可以吗？举个CSLA.NET的例子？
@Adil,
I'm not very experient user, anyway, this is the kind of model I'm using (also with NHibernate).
GUI - with all the web forms and so on
BLL - The catalogs that are responsible for creating instances of new objects
DAL - The place where classes responsible for interaction with NHibernate are implemented. The NHibernate mapping files are here.
Model - Class Library that is used by the BLL and DAL for data transfer object between.
Different patterns are used. For example, the BLL and DAL have a Factory class that allow access to an interface. The catalogs are Singleton classes. All of the catalogs are accessible using a master Singleton class representing my business logic top object (for example "Enterprise" => "Enterprise.PeopleCatalog".
Anyway, hope it helped...
@AngryHacker, thanks for the tip, could you give an example of CSLA.NET?