Question

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

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

相反的观点是数据层应该是对象无关的，并且纯粹处理简单的数据类型（字符串，bool，日期等）。

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

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

现在，我知道这是有可能发起宗教战争的问题之一，但我很感激社区对你如何处理这些事情的任何反馈。

TIA

Answer 1

这实际上取决于你对这个世界的看法 - 我曾经是在一个脱钩的阵营。 DAL只是向BAL提供数据 - 故事结束。

随着Linq to SQL和Entity Framework等新兴技术变得越来越流行，DAL和BAL之间的界限已经模糊了一些。在L2S中，特别是您的DAL与Business对象紧密耦合，因为对象模型具有1-1到您的数据库字段的映射。

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

Answer 2

你可以同时拥有两者。让数据层不知道您的业务对象，并使其能够使用多种类型的数据源。如果提供用于与数据交互的公共接口（或抽象类），则可以为每种类型的数据源使用不同的实现。工厂模式在这里很顺利。

Answer 3

我有一本优秀的书，涵盖了这个主题，是Data Access Patterns，由Clifton Nock撰写。关于如何将业务层与持久层分离，它有很多很好的解释和好点子。你真的应该试一试。这是我最喜欢的书之一。

Answer 4

Jeffrey Palermo写了一篇关于此事的好文章。他称之为Onion Architecture。

Answer 5

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

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

我这样做：

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

这让我可以传入一个普通的旧列表，如果这就是我需要的，或者是IList＆lt; T＆gt;的更智能的实现。（如ObservableCollection＆lt; T＆gt;）如果我打算从UI绑定它。这种技术还允许我从方法返回内容，如ValidationResult，如果发生错误消息，则返回错误消息。

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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