> Firstly, he advocates you organize your application deeper than the > default Rails skeleton; for example he says to put all of your models > under a "physical" directory (e.g. app/models/physical) and to > separate them by module (e.g. Physical::Projects::Project).
I would agree that organizing deeper can be useful. But if so, the groups should be meaningful to your application, not arbitrary (which from your account "physical" seems to be). Smaller Rails applications don't do it, not because of any bias against it, but because they don't have 188 models to organize. 10 to 30 models is not hard to manage. And while generally it makes sense to keep everything in one application, keep in mind that it is possible to have more than one application and still share a table, a model or pass data between them. Depending on the schema and requirements, a 188 model application might be happier as three 60 model applications that share a User model/table. To give a non-Rails example: Google needs to keep track of my login, but that doesn't mean Google Maps and Gmail have to be one application. > He also evangelizes Postgresql instead of MySQL I would say that's his personal preference and not gospel. MySQL, Oracle, SQLite and other flavors have their fans too. Do your own research as to which one is right for you. > He is against migrations because of the extremely > limited subset of SQL they allow for (i.e. no real constraints). Whatever your opinion about database constraints vs. application constraints, he obviously does not realize that migrations allow you to execute any SQL. > The problem with using the approach from Enterprise Rails is > that it pretty much means I cannot use the generators, unless I were > to redefine them to follow the "enterprise" structure. Generators are there to help 90% of the time. The other 10% you'll have to do by hand, modify what they give you or roll your own. Once you get the hang of it, you'll see that it will only take a minute or two longer to do it without generators. Don't let this be a major concern. > Basically - I'm wondering if I should be following the advice in the > book from the get-go when I design my application, or if I should > follow the best practices of the Rails community and not worry about > the "enterprise" stuff until I need to (at which point it may or may > not be too late). Also remember that I am fairly new to Rails but I > still want to do things the "right" way. I think a good rule of thumb in programming is not to build it until you need it. Otherwise you will spend a considerable amount of time maintaining code and keeping options open for the future that you may never use. It is not hard to implement the "enterprise recommendations" you mentioned (grouping controllers and models, upgrading databases, etc.) when you find you need them. Don't burden yourself with them until you do. Ideally a framework will allow you to build your application fast, not burden you with features you may never use, but still keep your options for feature modifications and application scalability open for the future. I think Rails does that well. Kevin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
