.NET 中的 DAL 和 BLL
Microsoft 针对 ASP.NET ( 2.0）应用程序。 我知道一些替代方案，并且我已经在这里阅读了相关问题。 但是我想知道这个提议的解决方案现在是否值得实施，您知道有什么具体的缺点吗？
我想开发供公司内部使用的 DAL/BLL 组件，以从各种应用程序和脚本访问客户和员工数据等。 然而，在我开始构建这些东西之前，我想确保这个解决方案是“好的”。 例如， BLL 传递数据表而不是封装任何内容，您不需要没有包含逻辑的独立业务对象。 它基本上只是一个哑层，可以稍微简化 CRUD 操作并允许控件的数据绑定。
在该领域有经验的人可以指出我这种方法的优点和缺点吗？
There is this DAL/BLL design suggestion by Microsoft for ASP.NET (2.0) apps. I know some of the alternatives and I've read related questions here on SO. However I wonder if this proposed solution is worth implementing nowadays, is there a specific downside you know of?
I want to develop DAL/BLL components for company-internal use, to access customer and employee data, etc from various applications and scripts. However before I start building that stuff, I want to be sure that this solution is 'good'. As example, the BLL passes datatables instead of encapsulating anything, you don't have isolated business objects that contain logic. It's basically only a dumb layer that eases the CRUD operations a bit and allows databinding for controls.
Could someone, who has experience in this field, point me out the pro's and con's of this approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我完全建议不要使用数据表。 研究一个域驱动设计实现，您的整个框架将与您可以传递到 List<> 的常规对象一起使用。 或可查询<>。 DataTable 是垃圾，甚至不应该再包含在 .NET 中。
我还建议考虑使用依赖注入/控制反转框架（例如 Microsoft Unity 或 StructureMap）来创建松散耦合的代码。
I fully recommend NOT USING DATATABLES. Look into a domain driven design implementation that your entire framework will work with regular objects that you can pass into List<> or Queryable<>. DataTables are garbage that shouldn't even be included in .NET anymore.
I would also recommend looking into using a Dependency Injection / Inversion of Control framework such Microsoft Unity or StructureMap to create loosely coupled code.
优点：
-简单的方法，一些数据映射是通过数据表为您完成的。
- 为触发选择、添加、更新和删除查询提供了一些便利。
- 可能适合带有很少表格的非常简单的设计。
- 适用于非自引用 ER 设计或具有少量查找表和简单/少量连接的 ER
-适合需要简单数据存储的地方。 IE。 当复杂的面向对象思想应用于“业务对象”时，这种模式会使事情变得更加困难。
缺点：
- 大型 OO 模型将在这种模式中挣扎
- 具有许多表、复杂关系或 OO 对象要求的复杂 ER 设计不适合此模式。 数据表对于像 LINQ 这样的代码内对象查询没有提供太多帮助。
- 大多数查询需要用 SQL 手动编写（这包括连接）。 是的，您可以使用查询设计器，但这没有多大帮助。
- 这种方法有很多代码重复。 正如您将在 BLL 类中编写大量 CRUD 方法（您也需要从头开始编写）。
结论：
这实际上取决于您的要求。 如果您的实现很小/简单，那么这可能是一个好主意。 但用这种方法来发展一个小想法会很困难。 更加面向对象的方法将为您以后的重构/扩展做好更好的准备。
这种模式也很古老/过时。 对象查询 IQueryable/LINQ 更流行，并且很快将成为更广泛的标准。 我建议你跳上这辆马车。 从长远来看，这对你的个人发展也有好处。 :D
一些链接：
pros:
- simple approach and some of the data mapping is done for you with the datatable's.
- offers some conveniences for firing Select, Add, Update and Delete queries.
- might be suitable for very simple design with few tables.
- suitable for non-self-referencing ER degigns or ER's with few lookup tables and simple/few joins
- suitable where simple data store is required. ie. where complex OO ideas should be applied to the "business objects" this pattern would make things more difficult.
cons:
- large OO models will struggle in this pattern
- complex ER designs with many tables, complex relationships or OO object requirements will not fit this pattern. the datatables dont provide much assistance for in-code object querying like LINQ.
- most queries need to be written by hand in SQL (this includes joins). yes, you can use the query designer, but this dont help much.
- there is a lot of code duplication in this approach. as in you will write lots of CRUD methods in your BLL classes (which you also need to write from scratch).
conclusion:
it really depends on your requirements. if your implementation is small/simple then this might be a good idea. but growing on a small idea will be hard with this approach. a more OO approach will set you up much better for refactoring/expanding later.
this pattern is also older/antiquated. object querying IQueryable/LINQ is more popular and will become a wider standard shortly. i'd suggest u jump on board this wagon. it will be better for your personal development in the long run too. :D
some links: