arborint wrote:I think the reason this does not get neatly resolved is that the solution is to build a custom Model that deals with the specific, complex needs. As has been mentioned in the past, trying to create an ever more complex, generalized solution (like OR/M libraries) quickly runs up against the law of diminishing returns. Building a custom Model is just so much simpler that it ends up being the direction to go.
Interesting. I think I understand what you mean.
Loosely translated to my example: I would better build a custom BlogPost model then trying to build a "cleaner" solution. I should just accept that there's some (or a lot of) logic in the methods of that BlogPost model.
So the best I can do (besides some mega-complicated ORM solution) is try to create some loosely coupled, clean models for the separate entities (author, post, category, etc), and then just accept that some other models (like the BlogPostModel) will have logic in them, will be tightly coupled to the other models, have some duplication, etc?
A related question then is how much to put in those "model" classes, and how much in the controllers. You'd say that logic goes in a controller. But on the other side, I'd like to keep my controller classes clean, without any db queries.