Reporting Service 技术路线

  最近启动的项目是关于微软Reporting Service的。公司决定用这个技术取代之前的Crystal report，毕竟这个是免费的。考虑到公司内部没有人精通此道，所以本着一贯认真谨慎的处理原则，从美国当地找了个顾问，做一些前期的研究和培训。很长一顿时间内，我们都没有拿到这个顾问的作品，所以只有凭借自己的感觉自行研究。微软的咚咚果然好用，一下子就做出了很多很炫的报表。而且基于自己的理解，对整体架构做了分析和设计。框架也基本成型。可就在这个时候，一次review让我们顿感哇凉哇凉的。第一，顾问采取的是服务端模式，而我们的所有考虑都是基于客户端的。第二，数据访问层采取的CLSA，而我们用的是微软的企业库。这两点实在太突然，让我们本来准备拿出去秀一把的咚咚偃旗息鼓。

  冷静下来，思考顾问的思路。我们觉得服务端和客户端都有他的好处和坏处。服务端模式有一个硬伤就是必须要求所有的客户都购买MS SQL Server，而对于基于Oracle的客户来说增加了费用成本和管理成本。我想我们公司也不可能抛弃这些客户的。第二就是部署起来很麻烦，增加了我们的实施成本。我们不仅需要处理自己代码的升级，还得了解如何自动化的去升级服务器上的报表模板。而且这些报表模板的版本如何控制，未尝可知。不过，服务端的优势也很明显，Reporting Service从2005升级到2008，客户端没有改动，只有服务端做了升级，整个文件的Schema完全不同，原有的报表组织方式已经消失了，也就说整个设计理念已经不同。当然，其实这也是一个问题，那就是升级的兼容性问题，不晓得2010会不会兼容2008设计出来的报表，整个升级是不是平滑。未知数。另外一点，采取服务端模式的话，对整个客户端的要求就很少，这样当我们有多种客户端的时候就会显得很简单。

  我觉得项目到了现在双方出现这么大的分歧，应该说是沟通引起的。当然，前期的研究也没有白费，正是因为有了之前的基础，我们在面对新的Schema的时候才一点不惊慌。应该来说，主要是觉得采取服务端模式后，系统架构的很多亮点就没有了，只能当作个人收获，而不能拿出来炫了。比较遗憾。所以，我还是力主不遗余力的去主动沟通还是很重要的。