Where the model meets the view - who filters, orders and pages?

His full comment was:

"It seems to me that what initially (I assume) was intended to be a way to relieve developers of writing repetitive CRUD activities is becoming something which may in fact endanger something we are all aiming for - encapsulation, decoupling, blah blah. The more complex the ORM becomes, the more likely that the entire implementation becomes brittle.

Better leave a lot of the ordering and filtering elsewhere in the application

In fact i do a lot of this stuff in the view part of may apps (shock horror). As far as I am concerned the business object/service returns a record set. If it is filtered/sorted because of intrinsic business rules, then it will be, but often these choices can be left to the presentation of data. If a user asks for a recordset to be ordered by date is that the role of the business component? Not necessarily"

He raised a really important point. What is the responsibility of the model? To return a recordset or to return a specific sorted, filtered, ordered view of the recordset.

Theoretically I quite like the idea that the model is responsible for returning the general recordset (all admin users, all products within this category, all invoices over 30 days old) and the paging/ordering/filtering should be treated like a flex control or data grid with a view helper cfc handling all of that. I think it is fairly easy to distinguish the intent of a filter as to whether it belongs in the model or in the view (the view doesn't have to mean in the display templates - you can have view cfc's just as you have model cfcs).

However, in practice this becomes a problem with larger recordsets as if I want to order 50,000 products by price and see the first 10 and then order by title instead, I would need to pass all 50,000 records to the view (which is not performant) or allow the view to speak directly to the database (which will happen over my cold dead fingers!).

The question then is whether you use different criteria for each object and get the service layer to handle filtering and ordering only for objects with more than a certain number of records. I don't like the inconsistency of this and like even less the thought that the interface to a given object would vary as a funciton of how many records it currently contained.

Because of that, I've decided that the model should be fully capable of returning pages, ordered and filtered recordsets and the getbyFilter() interface should support that (and the contorller should be able to pass across the appropriate input variables). If you want to use a flex front end or a data grid control on the front end, all you have to do is not choose to set the paging and other criterias on the model call and to handle that on the front end if you really need that (obvious use case: flex front end and modestly sized recordset).