I really feel that its horses for courses. Writing code in anticipation of a requirement is folly. That being said, exposing the internals of your classes locks you into a cycle that can be difficult to break out of. Good encapsulation is at the heart of object oriented design, as is separation of concerns. It is an ongoing argument as to where the lifecycle of an object ends and where the business of object store persistence begins. I have never seen a ORM framework that doesn't in some way compromise the line between object persistence and object modelling. You can spend a great deal of time worrying about exactly what you call save on but in the end I don't think it really matters that much.
Many applications would be hideously overcooked by applying ridiculous Java EE like layering. It would grossly inflate the effort required to create them and likely yield no benefit whatsoever. In a world where the average web application has a shelf life of under 3 years, you really need to ask yourself how much future proofing you want to enter into? Cheers, Adam On 11/09/2011, at 8:37 PM, Tim Uckun wrote: > Sooner or later somebody is going to ask you to write an API so you > might as well start by setting aside a directory for your API and > coding business logic in there. > > I like to keep my models and controllers pretty thin. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
