Object model design choice

I am currently working on a ASP.NET MVC reporting application using C#. This is a redesign from a PHP application that was just initially thrown together and is now starting to gain some more traction. So we are in the process of reworking the backend to have a more OO approach. One of the decisions I am currently wrestling with is how to structure the domain objects. Since 95% of the site is read-only I am not sure if the typical approaches are practical.

Should I create domain objects for the primary pieces of the application (ticket, assignment, assignee) and then create static meth开发者_StackOverflow社区ods off of these areas to pull the reporting data? Or should I just skip that part and create the chart data classes and have some 'get' method off of these classes? It's not a really big application and currently I am the only one developing on it. But I feel torn as to which approach to take. I feel that the first one is the better choice but may be overkill given that the majority of uses is for aggregate reporting.

Does anybody have some good insight on why I should go one way or another?

The approach I would take is first to draw a conceptual model of the problem domain. My preferred method is Object Role Modelling but there are others, e.g. entity relationship modelling.

I would then derive my object model from this conceptual model. Behaviours defined by the problem domain should then be added to the objects in this model, e.g. adding a book to a book store, withdrawing money from an account.

Other behaviours, e.g. persisting the data in a database, which, ultimately, the user does not care about in isolation, should be added to appropriate objects created for these purposes, e.g. a unit of work object, which would form a data access layer (DAL).

The model in your MVC project, in this case, would then consist of the domain objects augmented by the DAL and should lend itself naturally to the creation of your required views and controllers.