Django and Rails solve a problem that you can argue is much more common: writing concise yet readable code without needing reams of boilerplate to handle common cases."
Yes! I work for a commercial mathematics company that does OR consulting. We deliver our tools to our customers via SaaS and the user base is basically nothing in comparison to what I have scaled for in the past. The biggest problem we have is writing maintainable code at speed, performance is only a concern on a UX side and is easy to manage.
[although I will add this - I did comment on one of the Ruby articles that sparked this debate that I feel that language communities are repeatedly solving similar problems in isolation]
> Models are intended to serve only as an abstraction to the database.
> They are meant to be 'models of data'.
TL;DR: MVC Model is Logical model - business object (invoice) with business logic (delete_line_item), Rails Model is Physical model - persistence layer for RDBMS (add, update, delete, find rows).
In all but the most trivial applications, the latter assertion contradicts the former, and the former, is just outright wrong.
In MVC, Models are meant to model the logical objects of the system.
An invoice is an object one which one acts. It is probably composed of several other objects (header, line items, addresses, etc.) which may in turn be composed of other objects.
Only the most trivial application have a one-to-one mapping from RDBMS rows to objects, which is what the OP asserts.
One does not write one's Models with the persistence layer in mind, one writes them with the business logic in mind.
So to me, this is where Rails gets the name Model wrong. The untrained, just starting out with rails learn that business logic goes in the model, so there is goes. But add_address() has no business living int he rails Model file for the invoice header, because that model is meant to be dedicated to manipulating invoice_header records in our RDBMS.
mew , we all lived the Java/JEE nightmare , and pragmatic programmers got us out of that mess, with no desire to go back to that stuff. I'll take ruby/active record flaws over the "bloated and unecessary entreprise pattern" code anytime.
I think that the most important idea may be in the title.
Yes, every new platform or framework reinvents the wheel, because they are almost all designed to do basically the same things, like CRUD.
I think the only way to avoid reinventing the wheel is to to adopt a common machine-processable abstraction that is at a higher level than the language and domain and use that to build the language and platform. Some type of knowledge representation maybe. Of course I'm not suggesting that is an easy thing to do.
"Models are intended to serve only as an abstraction to the database"
I'm really tired of hearing this unqualified argument. Fat models is not a creed. It's a practical and natural design choice that we've made because it fits real world workflows best. Do you really want to be copy/pasting your order total calculation logic into 5 separate controller actions? Obviously not. And fat models doesn't mean 800 line source files. On reasonably sized Rails applications the logic gets bundled into nicely organized and maintainable concerns.
I am not against fat models. However, the point of separating code into tiers makes it cleaner. The author does approve of concerns. His point is models are becoming too fat over time and people need to follow techniques like concerns and use cases to take out business logic. Essentially something already well known in other platforms is unknown in these communities.
I've been thinking the same thing recently, what with the debates about where logic goes in Rails apps (was here on HN a few days ago), and the debates about concerns etc. that I've seen on Rails oriented blogs and twitter accounts. I'm a .NET developer that has always admired rails (and dabbled in it a bit myself), but I have to say in .NET land these are all solved problems, and everybody just gets on with building their apps.
Seems to be missing the obvious; ruby and python (with some framework sugar) will mostly allow you there quicker than writing java with its framework sugar. I guess the trade off is rather quick to write as opposed to quick to execute. Interestingly, i also hear my colleagues say this about C and Java. Seems to be a recurring question of human understanding vs machine, no?
Possibly, but like most technology there's is a set compromises you're willing to make. Rails and Django seem to be focused on getting something up and running ASAP and then dealing with whatever scaling issues you're going to have when you know exactly what they're going to be. Face it, a good amount of webapps out there won't need to be sharded. 37Signals just threw hardware at basecamp for a while (they still do?). Instagram made a few tweaks to django once they started growing rapidly, same with Disqus and i'm going to assume Pinterest did something similar as well. I would focus on the product rather than how to scale it in the early on. Once you hit the point of "How am I going to deliver this product to a group a users an order of magnitude high than I am right now" you'll hopefully have good test coverage and be able to make the right choice among sharding/read-slaves/better caching with the metrics you're able to collect.
The latest Java/Spring/JEE platforms are much more lightweight than they were 5 years ago. Look at annotated JAX-RS and you'll be amazed. You defectors should really give it a objective try. Nowadays us Java guys can focus on building our applications because our frameworks and APIs are so mature.
"Models are intended to serve only as an abstraction to the database. They are meant to be 'models of data'."
It's about Ruby or common? Because I'm sure Models could have 0 code of working with database and business-logic only. It depends on architecture of project.
Model classes in Rails inherit ActiveRecord::Base. So, you can call a class method like update_all which is equivalent to an update statement on the table.
'Models could have 0 code of working with database and business-logic only'
Well the business logic creeping in is one of the issues here. That is why there are attempts to separate out the business logic as in case of the use of /app/use_cases [refer to the link of use cases in the article].
[+] [-] andybak|13 years ago|reply
"Not everyone is solving a scaling problem.
Django and Rails solve a problem that you can argue is much more common: writing concise yet readable code without needing reams of boilerplate to handle common cases."
[+] [-] hartror|13 years ago|reply
Not everyone is on the same growth path.
[+] [-] andybak|13 years ago|reply
[+] [-] vampirechicken|13 years ago|reply
TL;DR: MVC Model is Logical model - business object (invoice) with business logic (delete_line_item), Rails Model is Physical model - persistence layer for RDBMS (add, update, delete, find rows).
In all but the most trivial applications, the latter assertion contradicts the former, and the former, is just outright wrong.
In MVC, Models are meant to model the logical objects of the system. An invoice is an object one which one acts. It is probably composed of several other objects (header, line items, addresses, etc.) which may in turn be composed of other objects.
Only the most trivial application have a one-to-one mapping from RDBMS rows to objects, which is what the OP asserts.
One does not write one's Models with the persistence layer in mind, one writes them with the business logic in mind.
So to me, this is where Rails gets the name Model wrong. The untrained, just starting out with rails learn that business logic goes in the model, so there is goes. But add_address() has no business living int he rails Model file for the invoice header, because that model is meant to be dedicated to manipulating invoice_header records in our RDBMS.
[+] [-] camus|13 years ago|reply
[+] [-] ilaksh|13 years ago|reply
Yes, every new platform or framework reinvents the wheel, because they are almost all designed to do basically the same things, like CRUD.
I think the only way to avoid reinventing the wheel is to to adopt a common machine-processable abstraction that is at a higher level than the language and domain and use that to build the language and platform. Some type of knowledge representation maybe. Of course I'm not suggesting that is an easy thing to do.
http://en.wikipedia.org/wiki/Knowledge_representation_and_re...
[+] [-] SiliconAlley|13 years ago|reply
I'm really tired of hearing this unqualified argument. Fat models is not a creed. It's a practical and natural design choice that we've made because it fits real world workflows best. Do you really want to be copy/pasting your order total calculation logic into 5 separate controller actions? Obviously not. And fat models doesn't mean 800 line source files. On reasonably sized Rails applications the logic gets bundled into nicely organized and maintainable concerns.
[+] [-] dknight|13 years ago|reply
[+] [-] kamau|13 years ago|reply
[+] [-] benhoskins|13 years ago|reply
[+] [-] dknight|13 years ago|reply
[+] [-] wriq|13 years ago|reply
[+] [-] camus|13 years ago|reply
[+] [-] rbut|13 years ago|reply
In what ways is Django sub-par compared to Rails?
[+] [-] axlerunner|13 years ago|reply
[+] [-] EugeneOZ|13 years ago|reply
It's about Ruby or common? Because I'm sure Models could have 0 code of working with database and business-logic only. It depends on architecture of project.
[+] [-] dknight|13 years ago|reply
'Models could have 0 code of working with database and business-logic only' Well the business logic creeping in is one of the issues here. That is why there are attempts to separate out the business logic as in case of the use of /app/use_cases [refer to the link of use cases in the article].