ASP.net中报告应用程序的最佳架构(带动态源)

Nov*_*ice 3 c# asp.net-mvc wcf reporting

简单的要求是这样的.

  • 它是一个具有多个视图的图表应用程序(有点仪表板)(图表,PDF和Excel)
  • DataSources可能主要来自Oracle,但还有其他数据源,如Excel,平面文件....等.

  • 图表库将是组件艺术(我想尝试新的asp.net图表,但因为它已经在其他应用程序中使用,他们希望继续)

正如我告诉你的那样,我们已经拥有了一个应用程序,它就像基本的3层,包含一些DTO,主要是DataTables;我觉得任何数据模型都与Views紧密结合,他们希望继续使用相同的:)

我想为此提出一个新的架构,我需要你的诚实评论.

我认为

  1. 它应该使用传统的MVC模式设计,因为有一个模型和不同的视图(图表,excel,pdf)
  2. 具有1)安全性(提供者模型)的固体服务层(Enterprise Lib)2)数据源抽象(平面文件,oracle,excel)3)缓存(每个报告都有自己的刷新时间,数据/视图可以相应地缓存4)错误记录5)健康监测

3)使用WCF服务来公开视图或DTO

4)完成AJAX和部分渲染

5)开发一个可靠的wcfservice,它将采用datamodel名称和视图(chart,excel,pdf然后相应地返回视图).

请指导我,我想构建一个可以重用的松散耦合和可配置的架构.

Alr*_*ric 5

诚实的回答:听起来你要么过度设计,要么你不负责任地重新发明轮子.

我想构建一个可以重用的松散耦合和可配置的架构.

这是一个可爱的目标,但这是否是这个项目的要求?我猜它不是一个基本要求,至多是一个很好的东西.业务似乎需要一个包含一些可导出图表和报告的仪表板,并且您建议构建一个平台.这是经典的过度工程.

如果您真的需要一个可重复使用的平台,那么使用复杂且可训练的创作工具构建一个直观,强大,安全,可测试,可配置,可维护的报告平台需要相当大的精力和技能.

即使您构建了一个完美的平台,您也将拥有一个其他人都不知道的自定义系统.如果您使用已建立的BI /报告平台,您可以雇用已经了解该技术的人员或指出已经存在的培训材料的人员.

换句话说,构建将变得困难且成本更高,这对于组织在未来几年内使用来说是糟糕的,但也是困难的和更昂贵的,这更糟糕.我经常选择构建而不是购买,但报告是已知问题,已经被商业平台很好地解决了.

所以,当然,这种架构听起来很合理.并且在不了解更多有关要求的情况下,无法判断:也许您确实需要从头开始构建这个,但是根据您的描述"绘制应用程序(有点仪表板)",构建报告平台听起来不必要,尽管可能非常有趣.