logo标签列表

.NET中的DAL和BLL是什么？

c#asp.netdatatabledata-access-layerbll
9

有一种名为Microsoft ASP.NET (2.0)应用程序DAL/BLL设计建议。我知道一些替代方案，并且我已经阅读了相关的SO问题。然而，我想知道这个提出的解决方案是否值得实施，你知道具体的缺点吗？

我想开发公司内部使用的DAL/BLL组件，以从各种应用程序和脚本中访问客户和员工数据等。但在我开始构建这些内容之前，我想确保这个解决方案是“好”的。例如，BLL传递数据表而不是封装任何东西，您没有包含逻辑的隔离业务对象。它基本上只是一个愚蠢的层，稍微简化了CRUD操作并允许控件进行数据绑定。

有经验的人能否指出这种方法的利弊？

您可以使用以下链接开发BAL和DAL：http://www.c-sharpcorner.com/UploadFile/paulabraham/Building3TierAppPA11282005053625AM/Building3TierAppPA.aspx 在该链接中提供了源代码、演示和说明。 - Shyam sundar shah
2个回答
12

我完全不建议使用DATATABLES。研究一下领域驱动设计实现，让您的整个框架可以使用常规对象，您可以将它们传递到List<>或Queryable<>中。DATATABLES是垃圾，不应再包含在.NET中。

我还建议研究使用依赖注入/控制反转框架，如Microsoft Unity或StructureMap，创建松散耦合的代码。

1
我同意，但不至于认为DataTables不应该包含在.NET中。它们仍然属于System.Data命名空间，并且用于使用来自数据库的数据创建快速演示应用程序非常有用。看一下这个对象的好的一面吧。:-P - jerbersoft
@jerbersoft，它们至少应该被弃用。 - Chris Marisic
9
优点：
- 简单的方法和某些数据映射已经在datatable中完成。
- 提供了一些方便的功能，可以执行选择、添加、更新和删除查询。
- 可以适用于非常简单的设计，只有少量表格。
- 适用于非自引用ER设计或ER中具有少量查找表和简单/少量连接的情况。
- 适用于需要简单数据存储的情况。即：如果将复杂的OO思想应用于“业务对象”，则此模式会使事情更加困难。 缺点：
- 大型OO模型在此模式下会受到影响。
- 具有许多表格、复杂关系或OO对象要求的复杂ER设计将无法适应此模式。datatable不能像LINQ一样提供很多辅助的代码内对象查询。
- 大多数查询需要手动编写SQL（包括连接）。是的，您可以使用查询设计器，但这并没有帮助太多。
- 此方法中存在大量代码重复。也就是说，您将在BLL类中编写大量CRUD方法（您还需要从头开始编写）。 结论： 这真的取决于您的要求。如果您的实现很小/简单，那么可能是个好主意。但是，使用此方法很难在小想法的基础上扩展。更OO的方法将为你今后的重构/扩展提供更好的基础。 此模式也比较老/过时。对象查询IQueryable/LINQ更流行，不久将成为更广泛的标准。我建议您跟上这个潮流。长远来看，这对您的个人发展也更有好处。:D 一些链接：
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接