您使用什么.Net 业务逻辑层框架？
我被要求通过在其中添加一些表和类来扩展一个简单的遗留应用程序来扩展功能。
这是一个 .Net 1.1 应用程序，我现在已成功升级到 .Net 3.5
现在我的问题是，对于这些新表和类，我想添加一个 ORM 和一个业务逻辑层，我可以在将来将其扩展到遗留类每当我需要触摸一段代码时。
我知道很多可以使用的 ORM 工具，例如 实体框架和NHibernate。
对我来说，问题在于决定使用哪个业务逻辑层，我使用了 csla.net过去取得了良好的效果，但我的问题是还有其他真正的替代方案吗？
I've been asked to extend a simple legacy application by adding a few tables and classes in it to extend functionality.
This is a .Net 1.1 application which I have now successfully upgraded to .Net 3.5
Now my problem is that for these new tables and classes I wanted to add an ORM and a business logic layer that I can in the future extend to the legacy classes whenever I need to touch a piece of that code.
I know about a quite few ORM tools that I can use, e.g. Entity Framework and NHibernate.
For me the problem is in deciding what business logic layer to use, I've used csla.net in the past with good results but my question is what other real alternatives are out there ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除了使用工具来基于数据库或数据层代码生成一些业务对象和/或 DTO 之外，我个人对业务层框架没有太大需求。
我相信 CLSA.NET 可以帮助一些人进行验证，并尝试使应用程序“分层”变得更容易。
有些人可能需要一个框架或类似的东西来帮助序列化业务对象，但版本控制问题通常非常严重，所以我非常努力地避免需要它。
我的业务层几乎是业务对象、业务逻辑和业务规则。我尽量保持最小化，更喜欢简单。
Other than using a tool to maybe code generate some of the business objects and/or DTOs based on the database or data layer, I don't personally have much need for a framework for the business layer.
I believe CLSA.NET helps some with validation, and tries to make it easier to "tier" an application.
Some people may want a framework or something similar to help serialize business objects, but the versioning issues are usually pretty severe, so I work pretty hard to avoid needing that.
My business layers are pretty much business objects, business logic and business rules. I try to keep it minimal, preferring simplicity.
设计可维护应用程序的最佳方法是不依赖任何框架或代码生成工具来创建域层（即业务层）。让您的基础设施尽可能远离您的领域（基础设施无知），并避免包罗万象、紧密耦合的框架，这些框架试图为您做所有事情。对于基础设施问题，寻找有针对性的框架，或者使您能够仅选择您需要的那些问题的框架。
The best approach to designing maintainable applications is to not rely upon any frameworks or code generation tools for the creation of your domain layer (i.e. business layer). Keep your infrastructure away from your domain as much as possible (Infrastructure Ignorance) and avoid all-encompassing, tightly coupled frameworks which try to do everything for you. For infrastructure concerns, seek out targeted frameworks, or frameworks which enable you to chose only those concerns which you need.