使用 DTO 模式同步两个模式？
我需要同步两个数据库。 这些数据库存储相同的语义对象，但在两个数据库中物理上不同。
我计划使用 DTO 模式来统一对象表示：
DB ----> DTO---->映射（获取器/设置器）----> DTO----> DB
我认为这比在每一侧使用 SQL 查询进行物理同步更好，我使用 hibernate 添加抽象并同步对象。
你认为这是个好主意吗？
I need to synchronize two databases.
Those databases stores same semantic objects but physically different across two databases.
I plan to use a DTO Pattern to uniformize object representation :
DB ----> DTO ----> MAPPING (Getters / Setters) ----> DTO ----> DB
I think it's a better idea than physically synchronize using SQL Query on each side, I use hibernate to add abstraction, and synchronize object.
Do you think, it's a good idea ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
上面很好地参考了《搭便车指南》。
我的两分钱。您需要考虑使用适合该工作的正确工具。虽然编写自定义代码来解决这个问题很有吸引力，但有许多工具已经可以为您做到这一点，将源映射到目标，进行从属性到属性的自定义转换，并且很可能会加快上市时间。
寻找 ETL 工具。我不熟悉开源社区中提供的工具，但如果您朝这个方向倾斜，我相信您会找到一些。您可能会考虑的其他工具有：Informatica、Data Integrator、SQL Server Integration Services，如果您正在处理空间数据，还有另一个名为 Alteryx 的工具。
蒂姆
Nice reference above to Hitchhiker's Guide.
My two cents. You need to consider using the right tool for the job. While it is compelling to write custom code to solve this problem, there are numerous tools out there that already do this for you, map source to target, do custom tranformations from attribute to attribute and will more than likely deliver with faster time to market.
Look to ETL tools. I'm unfamiliar with the tools avaialable in the open source community but if you lean in that direction, I'm sure you'll find some. Other tools you might look at are: Informatica, Data Integrator, SQL Server Integration Services and if you're dealing with spatial data, there's another called Alteryx.
Tim
使用 ORM 执行此操作可能比精心设计的 SQL 脚本慢几个数量级。这取决于数据库的大小。
编辑
我想补充一点，这个决定应该取决于两个模式之间的差异程度，而不是您对 SQL 的专业知识。 SQL 如此常见，开发人员应该能够以干净的方式编写简单的脚本。
SQL还有一个优点，就是每个人都知道如何运行脚本，但不是每个人都知道如何运行你自定义的工具（这是我在实践中遇到的问题，如果迁移实际上是由其他人操作的）。
对于仅有略有不同的架构（例如名称或列值的简单转换），我会选择 SQL 脚本。这可能更加紧凑并且易于使用和通信。
对于具有重大差异的架构，将数据组织在不同的表中或将某些值从一个架构映射到另一个架构的复杂逻辑，那么专用工具可能是有意义的。编写该工具的最初努力很可能更重要，但一旦创建它就可以成为一种资产。
您还应该考虑非功能性方面，例如异常处理、错误记录、在较小的事务中分割工作（因为数据太多）等。
SQL 脚本确实可以变成“在这样的条件下“乱七八糟”。如果有这样的限制，SQL 将需要高级技能，并且往往难以使用和维护。
自定义工具可以演变成一个迷你 ETL，能够将工作分成小事务，很好地管理和记录错误等。这是更多的工作，并且可以成为一个专用项目。
决定权在你。
Doing that with an ORM might be slower by order of magnitude than a well-crafted SQL script. It depends on the size of the DB.
EDIT
I would add that the decision should depend on the amount of differences between the two schemas, not your expertise with SQL. SQL is so common that developers should be able to write simple script in a clean way.
SQL has also the advantage that everybody know how to run the script, but not everybody will know how to run you custom tool (this is a problem I encountered in practice if migration is actually operated by somebody else).
For schemas which only slightly differ (e.g. names, or simple transformation of column values), I would go for SQL script. This is probably more compact and straightforward to use and communicate.
For schemas with major differences, with data organized in different tables or complex logic to map some value from one schema to the other, then a dedicated tool may make sense. Chances are the the initial effort to write the tool is more important, but it can be an asset once created.
You should also consider non-functional aspects, such as exception handling, logging of errors, splitting work in smaller transaction (because there are too many data), etc.
SQL script can indeed become "messy" under such conditions. If you have such constraints, SQL will require advanced skills and tend to be hard to use and maintain.
The custom tool can evolve into a mini-ETL with ability to chunck the work in small transactions, manage and log errors nicely, etc. This is more work, and can result in being a dedicated project.
The decision is yours.
我之前已经这样做过，我认为这是在 2 个数据库之间映射的一种非常可靠且直接的方法。唯一的缺点是，每当数据库发生变化时，我都必须更新映射逻辑，但这通常很简单。
I have done that before, and I thought it was a pretty solid and straightforward way to map between 2 DBs. The only downside is that any time either database changes, I had to update the mapping logic, but it's usually pretty simple to do.