10

我正在与一位同事“讨论”在新应用程序中实现数据层的最佳方式。

一种观点是数据层应该知道业务对象(我们自己的代表实体的类),并且能够在本地使用该对象。

相反的观点是数据层应该与对象无关,并且纯粹处理简单的数据类型(字符串、布尔值、日期等)。

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

我同事的观点是,数据层不应该知道对象定义,只要数据传递得当,这就足够了。

现在,我知道这是有可能引发一场宗教战争的问题之一,但我希望社区提供任何关于您如何处理此类事情的反馈。

TIA

4

8 回答 8

5

这真的取决于你对世界的看法——我曾经在非耦合阵营中。DAL 只是为了向 BAL 提供数据——故事的结尾。

随着 Linq to SQL 和实体框架等新兴技术变得越来越流行,DAL 和 BAL 之间的界限变得有些模糊。在 L2S 中,尤其是您的 DAL 与业务对象非常紧密耦合,因为对象模型与您的数据库字段具有 1-1 映射。

就像软件开发中的任何事情一样,没有正确或错误的答案。您需要了解您的要求和未来的要求,并从那里开始工作。我不会再在达喀尔拉力赛上使用法拉利,就像我在赛道日使用路虎揽胜一样。

于 2008-08-14T10:38:04.677 回答
3

你可以两者兼得。让数据层不知道您的业务对象,并使其能够处理多种类型的数据源。如果您提供一个通用接口(或抽象类)来与数据交互,那么您可以为每种类型的数据源提供不同的实现。工厂模式在这里很顺利。

于 2008-08-14T10:28:43.070 回答
1

我拥有的一本涵盖该主题的优秀书籍是Clifton Nock 的《数据访问模式》。关于如何将业务层与持久层解耦,它有很多很好的解释和很好的想法。你真的应该试一试。这是我最喜欢的书之一。

于 2008-08-14T10:27:50.500 回答
1

Jeffrey Palermo 写了一篇关于这个的好文章。他称之为洋葱架构

于 2008-08-14T10:30:21.243 回答
0

我发现方便的一个技巧是让我的数据层“与集合无关”。也就是说,每当我想从我的数据层返回一个对象列表时,我都会让调用者传入列表。所以代替这个:

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

我这样做:

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

如果这就是我所需要的,这让我可以传入一个普通的旧 List,或者如果我打算从 UI 绑定到它,则可以传入更智能的 IList<T> 实现(如 ObservableCollection<T>)。这种技术还可以让我从方法中返回一些内容,例如 ValidationResult,如果发生错误消息,则包含错误消息。

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

于 2008-08-14T10:28:08.673 回答
0

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

除此之外,我认为尽可能多地分离数据和逻辑是一种很好的做法,但这并不总是可行的。逻辑和数据访问之间的纯粹分离使得连接和优化变得困难,这就是使 Linq 如此强大的原因。

于 2008-08-14T10:28:20.810 回答
0

在我们使用 NHibernate 的应用程序中,答案变为“介于两者之间”,因为 XML 映射定义(它们指定哪个表属于哪个对象以及哪些列属于哪个字段等)显然在业务对象层中.

它们被传递给不知道任何业务对象的通用数据会话管理器;唯一的要求是为 CRUD 传递给它的业务对象必须有一个映射文件。

于 2008-08-14T10:30:51.773 回答
0

旧帖子但在搜索类似信息时我遇到了这个很好地解释了它。

于 2008-10-11T13:24:06.287 回答