"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 sourc…
Are Rails and Django communities re-inventing the wheel?
11–20 of 24 posts
Re: Are Rails and Django communities re-inventing the wheel?
#12Yes, 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...
Re: Are Rails and Django communities re-inventing the wheel?
#13Here's the comment I left on the article: "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."
Not everyone is on the same growth path.
Re: Are Rails and Django communities re-inventing the wheel?
#14"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…
Re: Are Rails and Django communities re-inventing the wheel?
#15Re: Are Rails and Django communities re-inventing the wheel?
#16> 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 o…
Re: Are Rails and Django communities re-inventing the wheel?
#17Possibly, 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?)…
Re: Are Rails and Django communities re-inventing the wheel?
#18In what ways is Django sub-par compared to Rails?
Re: Are Rails and Django communities re-inventing the wheel?
#19> 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 o…
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.
Re: Are Rails and Django communities re-inventing the wheel?
#20Seems 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?