我正在从头开始研究一个小应用程序并使用它来尝试自学架构和设计概念。它是一个.NET 3.5,WPF应用程序,我正在使用Sql Compact Edition作为我的数据存储。
我正在处理业务逻辑层,刚刚开始编写DAL。我只是使用SqlCeComamnds发送简单查询和SqlCeResultSet来获得结果。我开始设计我的插入和更新方法,这就是问题 - 我不知道从BLL到DAL获取必要数据的最佳方法。我是否通过了通用收藏?我是否有一个包含数据库所有数据的大量参数列表?我是否只是传入实际的业务对象(从而将我的DAL绑定到BLL中的conrete?)。
我想过使用接口 - 只需将IBusinessObjectA传递给DAL,这提供了我正在寻找的简单性,而不会将我与当前的实现紧密联系起来。你们觉得怎么样?
答案 0 :(得分:5)
我认为你的问题没有一个简单的答案,因为根据具体情况有很多选择。我发现阅读下面的两本书有助于我更好地理解你描述的问题。
第二本书可在线获取。看here。
答案 1 :(得分:3)
我认为将Business对象传递给数据访问层是可以的。我认为BLL的工作只是处理其对象,检查是否遵循所有规则,可以保存什么,由谁,在哪些领域,时间等。
一旦它完成了它应该将它传递给DAL,我认为这是一个工作,弄清楚如何将它得到的东西转换为可以持久的东西,但它不会检查什么是持久或读取或只有这样,它才能做到。这可能是直接的,但是如果你的逻辑mdoels与你的数据模型1:1不匹配,那么DAL应该完成所有的转换。
关于将你的DAL绑定到BLL中的内容,我认为你应该担心反过来,将你的BLL绑定到你的DAL。我会使用一个接口来表示你的DAL(如在IRepository中),这样你就可以通过改变它所使用的IRepository的类型来使你的BLL调用任何类型的持久性机制(如果你使用IoC:P,则加分)。实现IRepository的具体类将与业务对象绑定,但是他们必须知道它们保存的是什么,不是吗?而BLL不必知道正在做什么。
答案 2 :(得分:3)
在DAL中传递业务对象是更简单,最快速的方法。它适用于小型项目,但也有相同的缺点:
1)业务对象是BLL层的一部分,如果在BLL中传递对象,则DAL将依赖于BLL。低层知道上层 - 这与层的想法完全矛盾。
2)业务对象通常非常复杂,可以直接在BD中保存。在这种情况下,最好引入新的“Mappers”中间层。
为了克服所有这些问题,我通常会独立于Business Objects创建与DAL的接口。我改为使用“Row”类 - 表示数据库或XML中的一条记录。在.NET 3.5中,linqtosql自动生成的类可用于此目的。
答案 3 :(得分:2)
如果我在你的位置,我可能会使用LINQ to SQL来定义我的数据访问层 - 它将为你节省大量的工作来维护所有SqlCeFooBar的东西并给你一个设计师(各种各样的)来维护你的使用SQL CE,否则您将缺少的数据库。
因此,在这种情况下,我可能会将业务逻辑层非常紧密地耦合到L2S层公开的实体。理由是实体是业务对象,尽管没有任何服务。
我可能不会让实体尽可能地获得与UI相同的层次结构。在这个级别,使用专门用于视图的模型更有意义 - 特别是考虑到你正在使用WPF。
当然,所有这些都取决于应用程序的大小和复杂程度。假设您正在使用SQL CE,我认为它是一个相当小规模的应用程序(单用户?)。