.net 两个应用程序之间的通信，SSIS是解决问题的方法吗？

与一个更传统的开发团队合作，我们遇到了这种情况：

我们有越来越多（目前有两个）的应用程序将访问通过其中一个应用程序的ui插入的一些常见数据，该应用程序可以称为主管理应用程序。由于其他应用程序只需要一些数据，或者需要使用不同的模式进行格式化，因此提出的解决方案之一是每个应用程序都有一个数据库，并以一定的频率运行一个同步作业，将数据从一个db更新到另一个db。由于这是一个常见的SOA场景，我很快就放弃了这个解决方案，转而采用面向服务的解决方案，其中数据存储在一个主存储库中，并通过公开的服务进行访问

---

因此，我想了解一下您的想法，因为我认为我可能会偏向于相对较新的技术，可能不会欣赏更传统的解决方案的价值。

我在选择技术时的建议是真正权衡利弊。“新”和“旧”会让你一直陷入陷阱。在任何特定的时间，总会有一个热门的新流行词出现，这可能是一个好方法，也可能不是一个好方法。让我们来分析一下：

SSIS包与服务的Pro：

• 您可以将数据转换为目标数据库，以符合引用完整性关系
• 访问和修改现有应用程序以访问此数据很容易
• 如果有少量数据要转换，此作业将快速运行
• SSIS包是一个很好的集中调试数据转换问题的地方
• 通过使用SSI转换数据，可以更轻松地实现安全性。您不必担心诸如服务到服务之间的Kerberos委托之类的潜在问题
• 在目的地访问数据本身会快得多，因为您不必发出另一个服务请求。您可以直接加入数据库中已有的数据

SSIS包与服务的冲突：

• 您无法在目的地实时访问源数据
• 如果有大量数据，或者如果这个包写得不好，可能需要很长时间
• 如果目标数据库数量快速增长，则必须经常修改SSIS包
• 您可以使用该服务设置自己的安全机制，以便控制和审核对其信息的访问
• 如果您的目标系统需要回写到一个中心源，那么将所有这些与SSI合并在一起可能是一个真正的难题

所以我把它归结为：

---

如果您正在回写到集中的源，或者在更新之间没有任何明显的延迟，那么服务是非常有意义的。否则，建议使用SSI复制数据。在我的位置上，我们使用SSI转换用户数据并将其导入到系统的数据库中，但我们使用服务来实现组织范围的日志记录基础设施

同意，尽管在这个特定场景中，所涉及方法的年龄确实会影响决策。不过，你的观点还是很有道理的。