数据层最佳实践

Question

我正在和同事讨论在新应用程序中实现数据层的最佳方法。

一种观点是数据层应该知道业务对象（我们自己表示实体的类），并且能够原生地处理这个对象。

另一个观点是数据层应该与对象无关，仅处理简单的数据类型（字符串、布尔值、日期等）。

我可以看出两种方法都可能是有效的，但我自己的观点是我更喜欢前者。这样，如果数据存储介质发生变化，业务层不需要（必须）改变以适应新的数据层。因此，从SQL数据存储更改为序列化XML文件系统存储将是一件微不足道的事情。

我的同事认为，数据层不需要知道对象定义，只要适当地传递数据就足够了。

现在，我知道这是一个有潜力引发宗教战争的问题，但我希望社区能给我一些反馈，告诉我你们如何处理这样的问题。

TIA

- ZombieSheep

Answer 1

这真的取决于您对世界的看法 - 我曾经处于未耦合阵营。DAL只是为BAL提供数据 - 故事结束。

随着Linq to SQL和Entity Framework等新兴技术变得更加流行，DAL和BAL之间的界限已经有些模糊了。特别是在L2S中，由于对象模型与数据库字段具有1-1映射，因此您的DAL与业务对象相当紧密地耦合在一起。

像软件开发中的任何东西一样，没有正确或错误的答案。您需要了解您的要求和未来的要求，并从那里开始工作。就像我不会在达喀尔拉力赛上使用Ferrari一样，也不会在赛道日使用Range Rover。

- KiwiBastard

---

我完全同意。数据访问层等的设计变得有些模糊了。虽然我总是倾向于将业务逻辑与表示层分开。MVC模式万岁;-) - Tobias N. Sasse

Answer 2

你可以同时拥有这两个优点。让数据层不知道你的业务对象，并使其能够与多种类型的数据源一起工作。如果为与数据交互提供一个通用接口（或抽象类），则可以为每种类型的数据源提供不同的实现。在这里，工厂模式非常适用。

- buyutec

Answer 3

我有一本非常好的书，涵盖了这个主题，它就是Clifton Nock的Data Access Patterns。书中有很多很好的解释和思路，可以教你如何将业务层与持久化层分离。你真的应该试一试，这是我最喜欢的书之一。

- Mario Marinato

Answer 4

我发现的一个有用技巧是让我的数据层“集合无关”。也就是说，每当我想从我的数据层返回对象列表时，我会让调用者传递列表。因此，不是这样：

public IList<Foo> GetFoosById(int id) { ... }

我这样做：

public void GetFoosById(IList<Foo> foos, int id) { ... }

这让我可以传递一个普通的 List，如果那就是我所需要的全部，或者一个更智能的 IList<T> 实现（比如 ObservableCollection<T>），如果我计划从 UI 进行绑定。这种技术还让我可以从方法中返回一些东西，比如包含错误消息的 ValidationResult。

这仍然意味着我的数据层知道我的对象定义，但它给了我额外的灵活性。

- Matt Hamilton

Answer 5

如果我现在要创建一个新的应用程序，我会考虑完全依赖于基于Linq的数据层。请查看Linq to SQL。

除此之外，我认为尽可能地解耦数据和逻辑是一个好的实践，但这并不总是切实可行的。纯粹的逻辑和数据访问分离会使连接和优化变得困难，这就是Linq如此强大的原因。

- Keith

Answer 6

在使用NHibernate的应用程序中，答案变成了“介于两者之间”，因为XML映射定义（它们指定哪个表属于哪个对象，哪些列属于哪个字段等）明显位于业务对象层。

它们被传递到一个通用数据会话管理器，该管理器不知道任何业务对象；唯一的要求是传递给它进行CRUD操作的业务对象必须具有映射文件。

- Jon Limjap