在报告应用程序中，是否可以抽象报告逻辑和数据库架构详细信息？
我有一个具有相当复杂的报告逻辑的 Reporting Services 应用程序，我正在尝试将该应用程序迁移到其他一些数据库。 (出于相同目的而构建但由不同软件公司开发的数据库。)
在中间使用 Web 服务/WCF 层是明智的决定吗？还可以考虑哪些选择？
最佳答案
在一般情况下，很难以一种一刀切的方式来做这种事情，但你可以尝试以下方法之一:
在数据库模式上构建一些 View 并 编写报告过程 那些。这意味着您在底层数据库架构方面具有一定的灵活性，并且可以使用 View 作为抽象层。
构建某种数据仓库 平台并编写ETL流程 从各种数据源填充它。这更灵活，但需要更多的努力来构建，并且只能通过定期刷新来工作。如果您的应用程序可以接受这种程度的延迟，那么我建议数据仓库系统是更好的方法。
数据仓库的主要优势在于，它针对报告进行了优化，并且在所有数据源之间具有一致的界面 - 您可以将它们合并到具有一种模式的单个数据库中。这些报告是根据该模式开发的。添加新系统是通过编写ETL流程来填充仓库来实现的；无论数据源如何，报告都会继续有效。
WCF是一个网络通信系统。您会发现很难让这种架构在逐个事务的基础上处理大量数据 - 批量加载 ETL 过程会更加高效。但是，如果您需要实时源(可能是交易大厅系统)，您也许可以使用类似的方法来实现。
如果您需要低延迟源，另一种方法是研究一种名为 Enterprise Information Integration 的工具类型。 。也许可以做到这一点的最广泛使用的工具是 Data Source View在 SSIS这确实为您提供了将任意数据源映射到一致模式的灵活性。它不像最好的 EII 工具那么复杂，但如果您需要进一步转换数据，您可以将 SSIS 包放在其上并使用它们作为报告的数据源。
但是，我从未构建过这样结构的系统，因此我无法真正保证它在实践中的效果如何。我猜想它会非常脆弱并且很难分解成可以进行单元测试的部分，因此对于一个非常复杂的系统来说，开发和维护将非常耗时。
如果您想调查市场上的其他 EII 系统 This link是有关 EII 和其他一些 EII 工具供应商的各种文章的目录。
关于wcf - 报告应用程序中的数据库抽象，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/383890/