我的老板希望我在不久的将来创建几个报告,我想他想使用sql Server Reporting Services部署报告.我不太清楚,这将是一个好主意,考虑到我们是一个很小的组织,我看不到我们充分利用或需要这个解决方案提供的功能,如设置用户,组和订阅.
虽然我以前没有使用过SSRS,但是我已经看了3天的在线讲座,看起来像是简单的情况下好的,但是变得很痛苦,当要求变得更加复杂时,也受到限制.我将在.net应用程序中部署报告作为本地报告(.rdlc),因为：
我宁愿加工使用.NET格式化数据,然后sql.当然可以使用CLR,但是这种路由似乎比在.NET应用程序中通常要处理的数据更难维护,更不理想.
>添加参数控件时UI的限制 – 如果我记得你对布局没有太多的控制.
所以我想我的问题是在什么情况下,SSRS工作良好,什么情况下不起作用？我的积分是有效还是我只是一个怀疑者？
解决方法
我使用了一点,并发现每个方法都有权衡.
>无论什么原因,.rdlc的设计师与.rdl的设计师有点不同.当一个在线例子对你的设计师做出假设时,它会变得很混乱.
>如果我试图与客户端无关,我一般喜欢SSRS部署的报告,因为基于.rdlc的报告要求您提供客户端.
>我通常喜欢基于.rdlc的独立应用报告,特别是对于没有数据中心的客户端.这些应用程序往往是应用程序和数据库都在客户机上.
>我喜欢LINQ,发现它更容易用作基于.rdlc的报告的数据源.
>在重构时,我与基于.rdlc的报告有爱/恨关系.将数据结构保存在单独的库中比您的报告很重要;否则,更改属性名称将导致您的构建由于报告而失败,但在构建之前,新的属性将不会在报表的数据源上可用.
>控制客户端(.rdlc为基础的报告)为您提供了如何呈现和收集参数值的无限灵活性,这是非常好的.
无论如何,我怀疑有什么教条式的做法,你应该坚持,除了“做有道理”.对我来说,在实践中,我使用基于.rdlc的小型客户端应用程序报告,并将企业级报告部署到SSRS服务器.
祝你好运！
