数据映射器和存储库之间到底有什么区别? [英] What exactly is the difference between a data mapper and a repository?

问题描述

好吧，我一直在尝试找出数据映射器和存储库之间的区别，但是到目前为止，我仍然没有.在我看来，专家程序员说:存储库是在集中查询构造代码的映射层上的另一抽象层".看起来可以理解，但仍然有些抽象.我之前读过这篇有关stackoverflow的文章，这让我更加困惑: 数据映射器模式与存储库有何不同模式?

Well I've been trying to find out the difference between data mapper and repository, but up to now I still have not. It seems to me that the expert programmer said "Repository is another layer of abstraction over the mapping layer where query construction code is concentrated". It seems understandable but is still somewhat very abstract. I read this article on stackoverflow before, and it just made me even more confused: How is the Data Mapper pattern different from the Repository Pattern?

我想我需要的是关于这两种模式如何不同，存储库做什么而数据映射器没有做什么，以及反之亦然的简单解释和具体/实践示例.你们中没有人知道一个很好的例子来说明数据映射器和存储库的概念吗?如果是相同的示例，那就更好了，一个示例使用数据映射器，另一个使用存储库.谢谢，我非常感谢.到目前为止，我还是很困惑...

I guess what I need are simple explanations and concrete/practical examples on how the two patterns differ, and what a repository does what a data mapper doesnt, and vice versa. Do anyone of you know a good example on illustrating the concept of data mapper and repository? It will be better if it's the same example, just one using data mapper and another using repository. Thanks, I'd very appreciate this. I am still very confused as of now...

推荐答案

假定您的应用程序管理Person对象，每个实例都具有name，age和jobTitle属性.

Suppose your application manages Person objects, with each instance having name, age and jobTitle properties.

您想保留此类对象，从持久性介质中检索它们，并可能进行更新(例如，在其生日时增加年龄)或删除.这些任务通常在创建，读取，更新和删除中称为CRUD.

You would like to persist such objects, retrieve them from the persistence medium and maybe update (say, on their birthday, increment the age) or delete. These tasks are usually referred to as CRUD, from Create, Read, Update and Delete.

最好将业务"逻辑与处理Person对象持久性的逻辑分离.这使您可以更改持久性逻辑(例如，从数据库更改为分布式文件系统)，而不会影响业务逻辑.

It is preferable to decouple your "business" logic from the logic that deals with the persistence of Person objects. This allows you to change the persistence logic (e.g. going from a DB to a distributed file system) without affecting your business logic.

您可以通过将所有持久性逻辑封装在Repository后面来做到这一点.假设的PersonRepository(或Repository<Person>)将允许您编写如下代码:

You do this by encapsulating all persistence logic behind a Repository. A hypothetical PersonRepository (or Repository<Person>) would allow you to write code like this:

Person johnDoe = personRepository.get(p=> p.name == "John Doe"); johnDoe.jobTitle = "IT Specialist"; personRepository.update(johnDoe);

Person johnDoe = personRepository.get(p=> p.name == "John Doe"); johnDoe.jobTitle = "IT Specialist"; personRepository.update(johnDoe);

这只是业务逻辑，并不关心对象的存储方式和位置.

This is just business logic and doesn't care about how and where the object is stored.

在Repository的另一侧，您同时使用了DataMapper和用于将查询从功能描述转换为功能的内容(从p=> p.name == "John Doe"转换为持久层可以理解的内容).

On the other side of the Repository, you use both a DataMapper and something that translates queries from the functional description (p=> p.name == "John Doe" to something that the persistence layer understands).

您的持久层可以是一个数据库，在这种情况下，DataMapper会将Person对象与PersonsTable中的一行进行来回转换.然后，查询翻译器将功能查询转换为SELECT * FROM PersonsTable WHERE name == "John Doe".

Your persistence layer can be a DB, in which case the DataMapper converts a Person object to and from a row in a PersonsTable. The query translator then converts the functional query into SELECT * FROM PersonsTable WHERE name == "John Doe".

另一个持久层可以是文件系统，也可以是选择将Person对象存储在两个表PersonAge和PersonJobTitle中的另一种DB格式.

Another persistence layer can be a file system, or another DB format that chooses to store Person objects in two tables, PersonAge and PersonJobTitle.

在后一种情况下，DataMapper的任务是将johnDoe对象转换为两行:一行用于PersonAge表，另一行用于PersonJobTitle表.然后查询逻辑需要将功能查询转换为两个表上的join.最后，DataMapper需要知道如何根据查询结果构造一个Person对象.

In the latter case, the DataMapper is tasked with converting the johnDoe object into 2 rows: one for the PersonAge table and one for the PersonJobTitle table. The query logic then needs to convert the functional query into a join on the two tables. Finally, the DataMapper needs to know how to construct a Person object from the query's result.

在大型，复杂的系统中，您希望使用小型组件，这些组件可以做细小，定义明确的事情，并且可以独立开发和测试:

In large, complex systems, you want to use small components that do small, clearly defined things, that can be developed and tested independently:

• 当Repository想要读取或保留对象时，业务逻辑会对其进行处理，而不关心如何实现.
• Repository当要在特定的持久性介质中读取/写入对象时，会处理DataMapper.
• 对于查询，Repository依赖于DataMapper提供的模式(例如，在PersonTable表的JobTitle列中找到jobTitle值)，但不依赖于任何实现的映射器.
• 对于DB持久性，DataMapper依赖于 DB层，可以将其与Oracle/Sybase/MSSQL/OtherProvider详细信息隔离.

• The business logic deals with a Repository when it wants to read or persist objects, and doesn't care how that is implemented.
• The Repository deals with a DataMapper when it wants to read/write an object in a particular persistence medium.
• For querying, the Repository relies on a schema provided by the DataMapper (e.g. the jobTitle value is found in the JobTitle column in the PersonTable table) but not on any implementation of a mapper.
• For DB persistence, the DataMapper relies on a DB layer, that shield it from the Oracle/Sybase/MSSQL/OtherProvider details.

这些模式不会有所不同"，它们只是揭示了不同的基本功能.

The patterns don't "differ", they just expose different basic features.

这篇关于数据映射器和存储库之间到底有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！