История изменений
Исправление den73, (текущая версия) :
1. Переносимость нужна далеко не всегда. Требование переносимости обычно кастрирует конкретную среду, не позволяя использовать «вкусности», которые обычно и делают труд производительным. Например, если речь идёт об SQL, вкусностью являются хранимые процедуры. Без них производительность бизнес-логики падает примерно на порядок. Таким образом, вместо того, чтобы сразу делать работу, применяя имеющийся набор инструментов, разработчик предаётся аскезам ради загробной жизни.
2. Термин «расширяемость» некорректен без указания куда планируется эта расширяемость. По природе вещей расширяемость в одну сторону затрудняет расширяемость в другую. Поскольку направления расширения заранее предугадать нельзя, расширяемость тоже можно назвать разновидностью готовности к загробной жизни.
3. От наличия слоёв логика работы приложения не упрощается. Находясь в одной среде, легче контролировать поток исполнения. Например, если обработка происходит на клиенте, это может быть просто вызов функции. Если обработка происходит на сервере и клиенте, вместо вызова функции требуется обмен событиями. Таким образом, слои не избавляют от спагетти, а лишь добавляют им новую размерность.
Аминь (по правде сказать, некогда обсуждать это; нам с Вами в одном проекте не работать, так что пусть каждый решает для себя сам).
Исправление den73, :
1. Переносимость нужна далеко не всегда. Требование переносимости обычно кастрирует конкретную среду, не позволяя использовать «вкусности», которые обычно и делают труд производительным. Например, если речь идёт об SQL, вкусностью являются хранимые процедуры. Без них производительность бизнес-логики падает примерно на порядок. Таким образом, вместо того, чтобы сразу делать работу, применяя имеющийся набор инструментов, разработчик предаётся аскезам ради загробной жизни. 2. Термин «расширяемость» некорректен без указания куда планируется эта расширяемость. По природе вещей расширяемость в одну сторону затрудняет расширяемость в другую. Поскольку направления расширения заранее предугадать нельзя, расширяемость тоже можно назвать разновидностью готовности к загробной жизни. 3. От наличия слоёв логика работы приложения не упрощается. Находясь в одной среде, легче контролировать поток исполнения. Например, если обработка происходит на клиенте, это может быть просто вызов функции. Если обработка происходит на сервере и клиенте, вместо вызова функции требуется обмен событиями. Таким образом, слои не избавляют от спагетти, а лишь добавляют им новую размерность.
Аминь (по правде сказать, некогда обсуждать это; нам с Вами в одном проекте не работать, так что пусть каждый решает для себя сам).
Исходная версия den73, :
1. Переносимость нужна далеко не всегда. Требование переносимости обычно кастрирует конкретную среду, не позволяя использовать «вкусности», которые обычно и делают труд производительным. Например, если речь идёт об SQL, вкусностью являются хранимые процедуры. Без них производительность бизнес-логики падает примерно на порядок. Таким образом, вместо того, чтобы сразу делать работу, применяя имеющийся набор инструментов, разработчик предаётся аскезам ради загробной жизни. 2. Термин «расширяемость» некорректен без указания куда планируется эта расширяемость