Marrying up consumer-defined aggregates (e.g. SQL counts) with 'pure' model objects?

Question

What is the best practice of introducing custom (typically volatile) data into entity model classes? This may sound like a bad practice first, but it seems to be quite a common scenario. In our recent web application we have developed a proper model and in most cases we are fine with loading model entities. But there are cases where we cannot afford loading an entire hierarchy of entities; we need to load, say, results of a couple of SQL COUNT’s or possibly some additional information alongside (or embedded inside) the model entities. So basically, the requirements and conditions are:

1. It’s a web application where 99.9999999999% of all operations are read operations.

2. They don’t need to process or do any complicated business logic. We just need to get data quickly to HTML.

3. In several performance critical cases, we need to load results of SQL aggregates which don’t fit any model properties.

4. We need an extensible way to introduce any new custom data if needed.

How do you usually solve this issue without working too much around your ORM (for instance raw data from db)? I’m sure this has been discussed many times, but I cannot figure out a good Google query to find anything useful.

Edit: Since I later realized the question was not very well formed, I decided to reformulate it and start a new one.

Answer 1

OOP purist like myself would go to the Decorator pattern. http://en.wikipedia.org/wiki/Decorator_pattern

But the thing is, some people may not need the flexibility it offers. Plus, creating new classes for each distinct operation may seem overkill, but it provide good compile type checking.

Answer 2

The best practice in my view is that your application consumes data using the Domain Model pattern. The Domain Model can offer business-logic methods for doing the type of queries that make sense and are relevant to your application needs.

These can fetch "live" results that map directly to database rows and can therefore be edited and "saved."

But additionally, the Domain Model can provide methods that fetch read-only results that are too complex to be easily saved back to the database. This includes your example of grouped aggregate query results, and also includes joined query result sets, expressions as columns, etc.

The Domain Model pattern offers a way to decouple the OO design of an application from the design of the physical database.

Answer 3

If you're just getting relational data to and from a browser, with little or no behavior in between, it sounds like your trying to solve a relational problem with an OO paradigm.

I might be inclined to dispense with the Object Oriented approach altogether.

Me team recently rewrote an application by asking "What is the simplest thing that can possibly work?" and "What is the closest language to the problem?". Our new app, replacing an OO one, ended up being 10 times smaller, faster, and cheaper.

We used SQL, stored procedures, XML libraries on the DB server, XSLT (to get the HTML), and javascript.