3 ms·

In my experience, projects written in frameworks like Rails an Django have a tendency to end up with business logic sprinkled everywhere: Persistence + Bus

In my experience, projects written in frameworks like Rails an Django have a tendency to end up with business logic sprinkled everywhere: Persistence + Business <-> Frontend + Business You end up with business logic in ORM code, POST validation, Javascript form validation... You usually want: Persistence <-> Business <-> Frontend That way you can extract a business API and be transparent whether it's making SQL queries, talking to a webservice, a file, or something else. Another mistake IMHO is going crazy on OO and having, e.g., an `Order` object encapsulate everything like validation, persistence, reporting, serialization, etc... You end up with an object that retains so much state that it's hard to test. By coupling data and function you also end up in a corner trying to do bulk operations efficiently, falling into an awful idiom of iterating objects and calling a method on them, leading scalability issues with N*M queries, and so on. The testable/scalable route is following a functional approach and designing your business API from the start around functions that deal with sets and take all the necessary state as a parameter, or data structure that represents the current state.

mercurial 13y ago
It's a general problem with poor programming practices. When you see people subclassing controllers to modify behaviour, it's clear something went wrong. On the other hand, splitting out your business logic (which should take clean data structures) and putting your persistence system in its own layer, you get a clean, decoupled system, which you may or may not reuse elsewhere, but that is certainly easier to understand and test than when "good design" means accessing the database in a controller or in a view. Framework or no framework, you'll get the same design from programmers who stare blankly when somebody says "separation of concerns".
jshen 13y ago
In my experience, projects written without frameworks like rails or Django have a tendency be worse than those that used a framework.

mercurial 13y ago

It's a general problem with poor programming practices. When you see people subclassing controllers to modify behaviour, it's clear something went wrong. On the other hand, splitting out your business logic (which should take clean data structures) and putting your persistence system in its own layer, you get a clean, decoupled system, which you may or may not reuse elsewhere, but that is certainly easier to understand and test than when "good design" means accessing the database in a controller or in a view. Framework or no framework, you'll get the same design from programmers who stare blankly when somebody says "separation of concerns".

jshen 13y ago

In my experience, projects written without frameworks like rails or Django have a tendency be worse than those that used a framework.