Applicable design patterns

Question

I must develop a simple web application to produce reports. I have a single table "contract" and i must return very simple aggregated values : number of documents produced in a time range, average number of pages for documents and so on . The table gets filled by a batch application, users will have roles that will allow them to see only a part of the reports (if they may be called so ).

My purpose is :

1. develop a class, which generates the so called reports, opened to future extension (adding new methods to generate new reports for different roles must be easy )
2. decouple the web graphic interface from the database access

I'm evaluating various patterns : decorator, visitor, ... but being the return data so simple i cannot evaluate which apply or even if its the case to use one. Moreover i must do it i less than 5 days. It can be done if i make a so called "smart gui" but as told at point 1, i don't want to get troubles when new roles or method will be added.

Answer 1

The road to good code is not paved with design patterns.

Good code is code that is readable, maintainable, robust, compatible and future-proof.

Don’t get me wrong: Design patterns are a great thing because they help categorise, and thus teach, the experience that earlier generations of programmers have accrued. Each design pattern once solved a problem in a way that was not only novel and creative, but also good. The corrolary is not that a design pattern is necessarily good code when applied to any other problem.

Good code requires experience and insight. This includes experience with design patterns, and insight into their applicability and their downsides and pitfalls.

That said, my recommendation in your specific case is to learn about the recommended practice regarding web interfaces, database access, etc. Most C# programmers write web applications in ASP.NET; tend to use LINQ-to-Entities or LINQ-to-SQL for database access; and use Windows Forms or WPF for a desktop GUI. Each of these may or may not fulfill the requirements of your particular project. Only you can tell.

Answer 2

KISS - keep it simple and stupid. You have five days. Create working application and if you have time refactor it to some better solution.

Answer 3

How about you use strategy pattern for the retrieving data? And use interfaces like following to keep it extendable at all times.

• IReportFilter: Report filter/criteria set
• IReportParams: Gets report parameters
• IReportData: Gets the report data in a result set
• IReportFormat: Report formatting
• IReportRender: Renders the report

Just thinking out loud.

Answer 4

hi thank you for your answers. I'm sorry, i realize i haven't provided too much infos. I live in a Dilbert world. at the moment i've got the following info : db will be oracle (the concrete db doesn't exist yet) , so no EF, maybe linqtodataset (but i'm new to linq). About new features of the application,due to pravious experiences, the only thing i wish is not to be obliged to propagate changes over the whole application, even if it's simple. that are the reasons i've thougth to design patterns (note i've said "if it's the case" in my question) . I'll KISS it and then will refactor it if needed , as suggested by ladislav mrnka, but i still appreciate any suggestion on how to keep opened to extension the data gathering class