I've just come across a great article at the WTF blog, The Mythical Business Layer... with some amazing comments. Not all of them the good kind of amazing, though.
Some people seem to get mixed up about two terms:
While any kind of duplication at specification level would prove catastrophic when trying to make any changes, duplication at implementation level is a MUST for both a good user experience and a well secured application (aka: good software). That leads to a third element: tests, which are the correct way to join a specification with no duplication, to an implementation with more or less duplication. Any time specification logic changes, all tests should fail. Any time some implementation logic changes, it's test should tell you if it complies with specifications. It's as simple as that.
All this talk about having a "good" framework -or whatever- in order to get rid of logic duplication at the implementation level, for some kind of "big enterprise applications"... it just gives me the creeps.
Of course, if your "specification" is actually your implementation, you may be in bigger trouble already. That is, unless your project is some kind of free software with more developers than you actually need (think: linux).
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| << < | Current | > >> | ||||
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
powered by
+
photos powered by

Nikon Coolpix 7600
+

Nokia 3650
Por cortesía de NokiaGame 2002

Esta obra está bajo una licencia Creative Commons salvo donde se especifique explícitamente otra licencia.