2

因此，据我了解，存储库层的整个想法是您可以快速轻松地将一种解决方案换成另一种解决方案。说，我想从 MySQL 切换到 MongoDB。我需要担心的是编写一个新的存储库层。

到目前为止，一切都很好。

问题是，MySQL 将（实际上很可能）使用整数作为主键，而 MongoDB 将使用字符串。或者我希望我的存储库层指向一个 Web 服务，谁知道他们使用什么样的 ID...

因此，为了给我的存储库层一个面向未来的接口，我不能有如下方法：

EmployeeRepository.getById(int id)

或者

EmployeeRepository.getById(string id)

那么一个人要做什么呢？始终使用字符串（或对象？？），然后让存储库层转换或转换它，但是它需要吗？

或者应用程序的模型是否应该有自己的内部 ID 方案，该方案与数据库的 ID 方案完全分离，并且您总是在该 ID 上获取？就像是：

EmployeeRepository.getByInternalId(int id)

这里的最佳做法是什么？

4

1 回答 1

0

因此，据我了解，存储库层的整个想法是，您可以快速轻松地将一种解决方案换成另一种解决方案

不，这个想法是抽象数据层以减少复杂性和代码耦合。而不是把所有东西都放在一个班级里，你会得到两个责任更明确的班级。

即使您使用存储库，从一种类型的数据层切换到另一种类型的数据层也并非易事。

然而。您可以决定在一个存储库中使用一种数据层（例如 vanilla ADO.NET），在另一个存储库中使用另一种类型的数据层（例如实体框架）。关键是您可以在每个特定用例之后调整您的存储库。这不会影响任何其他代码。

问题是，MySQL 将（实际上很可能）使用整数作为主键，而 MongoDB 将使用字符串。

您正在从错误的方式解决问题。您的应用程序的用户是否使用密钥？它必须采用特定格式吗？或者数据库生成的密钥可以吗？如果是这样，请使用数据库使用的任何格式。

如果您以后必须从 MySQL 切换到 Mongo，您仍然有很多工作要做（例如从表关系转移到文档）。

于 2013-03-27T11:31:13.033 回答