迁移共享数据库的数据库模式的最佳方法

时间:2017-12-12 11:47:41

标签: c# database entity-framework database-design architecture

我目前正在努力寻找一种方法来迁移到多个应用程序共享的数据库的新数据库模式,同时保持应用程序使用旧模式。

有多个应用程序使用自编写的类似ORM的库在共享数据库上执行CRUD操作。我在这个架构中看到的主要问题是:

  • 每个应用程序都实现了自己的业务逻辑,其中大量代码是冗余的或代码应该在每个应用程序中执行相同的操作,但实现方式不同而且难以维护
  • 由于每个应用程序直接与ORM库一起工作,其他应用程序无法知道某个数据何时被另一个应用程序更改而不监视/轮询数据库以进行更改
  • ORM库确实只实现有限的并发,没有事务并且相对较慢

为了解决冗余/不一致问题,我正在考虑实现分层架构。

  • 服务层
  • 业务层
  • 数据访问层
  • 数据库

然后,应用程序与服务层上的SOAP Web服务进行通信。 服务层使用业务层执行验证并应用业务逻辑。业务层使用数据访问层存储库。 我希望能够在客户端应用程序中使用业务层,使用另一个存储库实现,它不直接访问数据库,而是通过SOAP Web服务。

为了解决其他问题,我希望使用Entity Framework而不是自制的ORM库。但是数据库的模式是以一种通用的方式进行的。添加到数据库的每台机器的含义(数据库存储设施数据)添加了几个特定于机器的表。这会产生冗余表,名为 [machinename] _ [tablename] 。据我所知,实体框架或任何其他ORM都无法解决这个问题(无论如何,它的设计很差,可能意味着加快查询速度)。

计划是迁移到另一个数据库模式,但问题是需要更改使用数据库的所有应用程序以使用新的模式/ SOAP Web服务。这种情况不可能在一天之间发生,因此最好能保持一些应用程序保持不变,但仍然只能在一个数据库上运行。然后处理重新实现其他应用程序以使用Web服务。

我已经考虑过使用视图来模拟旧模式,这样旧的应用程序仍然可以使用更改的模式,但不幸的是,自制的ORM不支持使用视图。

我不希望任何人向我提供解决方案,而是提出一些基本方法和/或想法来改进系统的整体架构。

0 个答案:

没有答案