Внезапно в топик врывается кодогенерация через System.Linq.Expressions и DLR, который для реализации скриптов и придумали (см. IronPython, IronRuby и прочее).
Сразу, чтобы отмести обвинения в .net 4-only, DLR изначально был реализован в виде отдельной библиотеки — dlr.codeplex.com/
В Mono работает.
А System.CodeDom.Compiler изначально был нужен для кодогенерации именно в компиляторах.
Давайте все-таки использовать инструменты по назначению.
Это вы сильно загнули. Событийно программировали задолго до javascript.
А если вы про веб, то SOA 2.0 изобретен уже достаточно давно и реализаций было достаточно.
Грубо говоря — заводится так называемая «Модель представления» (может быть и неким конвертером из обычной модели с логикой, но обычно тупо класс с набором полей или даже просто словарь), которая заполняется в контроллере. В шаблоне логики нет, только подстановка полей из модели представления в нужные места.
Собственно, на самом деле, многие MVC-фреймворки на деле не MVC, а именно MVVM.
Но вот если использовать не MVC, а немного более прогрессивный MVVM, то вся логика представления (кроме разве что итераторных циклов) внезапно оказывается там где ей и положено быть — в контроллере.
Сложилось впечатление, что автор никогда не работал на больших проектах, в команде и в энтерпрайзе, со всеми его проблемами и бардаком.
1.1. ООП неэффективно только в совсем уж коротких скриптиках. По поводу производительности и серверных приложений вообще чушь какая-то. Время разработчиков стоит СИЛЬНО больше железа, соответственно, тратить его на разгребании вермишели…
1.2. Чушь. Вы не понимаете для чего нужно наследование.
1.3. У вас странные представления о «крутом» коде и о паттернах. Крутой код — тот который легко читать, в котором легко разобраться и, который ЛЕГКО расширять.
1.4. А как же принцип разделения логики и представления? Не являюсь пхп-программистом, но логика внутри шаблона — это же ужасно с точки зрения читабельности.
1.5. Если библиотека спроектирована правильно и выполняет задачи с заданными требованиями и ограничениями нет никакого смысла лезть внутрь, кроме случаев когда ее нужно расширять. Достаточно интерфейса. Если это фреймворк (а фреймворк — это НЕ библиотека) — то разработка под ним как раз и осуществляется за счет его расширения, соответственно, и знать его изнутри НАДО.
2-3. Да, согласен.
4. Выделять можно и НУЖНО. Опять же в целях читабельности, расширяемости и так далее.
5. Почти согласен. Но нужно учитывать что большинство систем все-таки живет постоянно развиваясь. Решая задачи нужно стараться оставлять возможность для расширения.
6. К сожалению, этот пункт слабо относится к содержанию статьи и выглядит как попытка оправдать свое мнение.
7. Чушь, кроме случая плохо спроектированной системы, развитие которой приводит к вермишелеобразности. Лечится живительным рефакторингом.
Hero Quest — оригинальное название, которое у Сиерры отобрали, так как уже существовала одноименная торговая марка.
Сразу, чтобы отмести обвинения в .net 4-only, DLR изначально был реализован в виде отдельной библиотеки — dlr.codeplex.com/
В Mono работает.
А System.CodeDom.Compiler изначально был нужен для кодогенерации именно в компиляторах.
Давайте все-таки использовать инструменты по назначению.
А если вы про веб, то SOA 2.0 изобретен уже достаточно давно и реализаций было достаточно.
Грубо говоря — заводится так называемая «Модель представления» (может быть и неким конвертером из обычной модели с логикой, но обычно тупо класс с набором полей или даже просто словарь), которая заполняется в контроллере. В шаблоне логики нет, только подстановка полей из модели представления в нужные места.
Собственно, на самом деле, многие MVC-фреймворки на деле не MVC, а именно MVVM.
Но вот если использовать не MVC, а немного более прогрессивный MVVM, то вся логика представления (кроме разве что итераторных циклов) внезапно оказывается там где ей и положено быть — в контроллере.
1.1. ООП неэффективно только в совсем уж коротких скриптиках. По поводу производительности и серверных приложений вообще чушь какая-то. Время разработчиков стоит СИЛЬНО больше железа, соответственно, тратить его на разгребании вермишели…
1.2. Чушь. Вы не понимаете для чего нужно наследование.
1.3. У вас странные представления о «крутом» коде и о паттернах. Крутой код — тот который легко читать, в котором легко разобраться и, который ЛЕГКО расширять.
1.4. А как же принцип разделения логики и представления? Не являюсь пхп-программистом, но логика внутри шаблона — это же ужасно с точки зрения читабельности.
1.5. Если библиотека спроектирована правильно и выполняет задачи с заданными требованиями и ограничениями нет никакого смысла лезть внутрь, кроме случаев когда ее нужно расширять. Достаточно интерфейса. Если это фреймворк (а фреймворк — это НЕ библиотека) — то разработка под ним как раз и осуществляется за счет его расширения, соответственно, и знать его изнутри НАДО.
2-3. Да, согласен.
4. Выделять можно и НУЖНО. Опять же в целях читабельности, расширяемости и так далее.
5. Почти согласен. Но нужно учитывать что большинство систем все-таки живет постоянно развиваясь. Решая задачи нужно стараться оставлять возможность для расширения.
6. К сожалению, этот пункт слабо относится к содержанию статьи и выглядит как попытка оправдать свое мнение.
7. Чушь, кроме случая плохо спроектированной системы, развитие которой приводит к вермишелеобразности. Лечится живительным рефакторингом.
XaocCPS, спасибо за статьи и ссылку.