Moving reporting logic into .NET code: Releasing fixes? [closed]

Question

At this moment, all of our reports are currently written in stored procedures. We want to start moving this away from a SQL platform and rather to focus most of the logic in .NET code. Reasons include the use of our ORM entities, ease of debugging, parallel processing, more unification with business logic, etc.

The problem we face is that by moving our report logic into .NET code, we cannot deploy support fixes as easily as running a script on our production environment. Releasing binaries means that the whole business has to stop using our application, which is almost impossible during office hours.

One solution is to separate each report into a new project and release just that DLL. The problem with this is that we have over 500 reports. Maintaining that will be a nightmare.

Has anyone experienced something similar or have any other solutions to this problem?

Thanks, Dave

Answer 1

Why not use Reporting Services? It is made for this! You can even train people in the business (non-devs) to create reports for you and publish them. There are so many features that users can just leverage. Authentication/Authorization, subscribe, export (PDF, Excel, Word), etc.

I wouldn't invest in rebuilding Reporting Services if I was you. I always stir away from writing reports as part of you application or in 'code'.

If you really, really want to do this (which I totally think you shouldn't do) then I would develop a separate service that generates reports (on a separate end-point) that you can call from your main application. Put a queue in the middle that stores 'report requests' when you need to update and the requests can be served after a restart.

Other option would be to go with dynamically loading assemblies. Let a filewatcher watch a folder and as soon as there is a new dll load it dynamically. Unloading is more difficult. You could restart the service when it is not so busy to get remove the old reports from memory or you need to create separate appdomains that you can unload.

A lot of options, but again, you will be wasting time by building and testing a custom report framework. I would go for plain SQL, even if you really like C#, this way you can hire a BI person that can just create reports instead of a dev.

Answer 2

I agree with a lot @bart's answer. My first reaction is that this seems like a unneeded reinvention.

However if you do need .net code and and convenience of declarative code, then why not use a DLR based language like iron python?

We've stored iron python in the db and loaded it on demand. Once jitted it's no different than any non dlr based code, deploying fixes was a dream.