Фреймворки, расширения, море технологий… для чего они?

Question

[Дмитрий Петров]

Ребята, объясните, пожалуйста, такую вещь. Может быть, я просто чего-то не понимаю. Читаю статью: чтобы работать с MVC4, рекомендуется взять Entity Framework 4.1 (Code First), MvcScaffolding, Ninject, NLog… куча пакетов и библиотек, без которых жизнь некомфортна.

Главный вопрос, который меня мучает постоянно — зачем все это? Зачем нужны десятки библиотек, плагинов, новые фреймворки? Ладно, положим, Code First облегчает саму разработку приложения. Но какой ценой? Были посты про то, что железо улучшается, а программы продолжают тормозить — не из-за этого ли? Десятки слоев, абстракций, отъедающие свои ресурсы. MvcScaffolding — кодогенерация, например CRUD панели. Опять же — неужели нельзя обойтись без этого простыми методами?

Может быть, я плохой разработчик, ковыряюсь на своей лужайке последние 5 лет и чувствую, что дико, невероятно дико отстаю от всех новомодных технологий и веяний. Пытаюсь понять, для чего это надо и просто не понимаю. Начинаю ковырять EF и понимаю, что как прекрасно жил без этого раньше, так и дальше проживу, жизнь это не сильно облегчит. MVC — круто, наворочено, универсально — но проигрывает по сравнению с тем же PHP по многим пунктам. Простой проект MVC — это около десятка папок, пять конфигов, куча контроллеров. Опять же — куда такие сложности? Для чего?

Порог вхождения во все это вроде бы невысок, да, но для поддержания собственного уровня приходится скакать по азам кучи технологий, при этом до корня не разбираясь ни в одной. Безумно уважаю людей, которые здесь в комментариях или в постах расписывают внутренности .Net технологий, но… когда вы в этом успеваете разобраться? Сколько лет ковыряния нужно, чтобы досконально знать, что вызов вот этого приведет к этому, вызов того делает то, причем на пять слоев абстракций в глубину, и особенность вон того дает преимущество в этом. И как можно вникнуть в технологию, чтобы применять её на практике, если через пару лет появляется более новая технология или в корне меняется старая и надо снова рыться, снова изучать и т.п.

Как остаться нормальным программистом не на задворках, не потерять хватку и не теряться во всем этом?


P.S. вопль души, простите, если кого-то обидел.

Answer 1

[catlion]

> зачем все это?

Если вам не нужно — не используйте. Я обычно прекрасно обхожусь без всего этого, за исключением NLog, т.к. сделать правильное логирование — та еще задача.

> Опять же — неужели нельзя обойтись без этого простыми методами?
Вы не раскрываете, что для вас простые методы. Если это WebForms со всей логикой в code-behind, то какие у вас объемы проектов и сколько над ними работает людей? Когда вы потеряетесь в лапше кода, вы обнаружите, что для WebForms рекомендован другой паттерн MVP.

> Простой проект MVC — это около десятка папок, пять конфигов, куча контроллеров
Неправда. Открываю солюшн: около 15k LOC (это немного, но и не HelloWorld), в веб-проекте только стандартные папки: Controllers, Views, Models. Куча контроллеров как правило ссодержит в себе мизерное количество кода, по сравнению с нижними слоями.

> MVC — круто, наворочено, универсально — но проигрывает по сравнению с тем же PHP по многим пунктам
Вы сравниваете апельсины с яблоками, MVC — это паттерн, PHP — язык. И на дотнете тоже можно писать в стиле Response.Write, и для PHP есть десятки MVC-фреймворков.
Если для вашей задачи не подходит MVC-паттерн, ну так существует масса других. Если вас напрягает количество контроллеров, есть разновидность MVC — Front Controller, и даже реализация для дотнета: FubuMVC,

> И как можно вникнуть в технологию, чтобы применять её на практике, если через пару лет появляется более новая технология или в корне меняется старая
Почитайте Фаулера, все эти абстракции стандартны и почти везде одинаковы.

> Фреймворки, расширения, море технологий… для чего они?
У разных задач — разные решения. Для того, чтобы был выбор.

> Как остаться нормальным программистом не на задворках, не потерять хватку и не теряться во всем этом?
Подтяните матчасть: начните с Фаулера, по вкусу добавьте Мартина. Сами решите, что вас устраивает, а что — нет.

В заключение хочу сказать, что на MVC свет клином не сошелся. Существует масса альтернативных паттернов и их реализаций для дотнета: Nancy, OpenRasta, FubuMVC, Manos, ServiceStack…

Comments

[Дмитрий Петров]

спасибо!

[catlion]

Почему популярна связка ASP.NET MVC + Entity Framework? Потому что стал моден Ruby on Rails (это, между прочим, опять стандарный паттерн ActiveRecord), и возник запрос в среде дотнет-разработчиков. И Microsoft решил запрыгнуть на эту волну, вот и все. А дальше покатилось — включилась пиар-машина, появились тысячи инструкций, мануалов, книг, скринкастов, подкастов и прочего. Это не значит, что это теперь единственный true-way делать веб-приложения на дотнете. Хотя, рассматривая альтернативы, я бы имел ввиду, что за ними не стоят такие ресурсы.

[Сергей Протько]

Между тем Entity Framework это неплохой ORM.

Answer 2

[javax]

Если Вы пишете большое приложение, которое делают несколько человек, которое нужно сопровождать, то фреймворки экономят очень много времени. Конечно же не бесплатно, а ценой худшей производительности (т.е. нужно более серьезное железо). Я не специалист в PHP, могу сказать про Яву. Функциональность, которую мне дадут Spring, Hibernate, GWT — я бы сам писал годами.
Конечно в каждом конкретном случае надо решать — нужен ли фреймворк, и если да то какой…

Answer 3

[TyVik]

Сколько лет ковыряния нужно, чтобы досконально знать, что вызов вот этого приведет к этому

Порой достаточно и пары часов. Дело в том, что человек с этим может столкнутся, а может и нет. В первом случае просто стоит задача разобраться. Я же постоянно стараюсь смотреть в исходники — порой они лучше документации.
По поводу такого количества слоёв абстракции — без этого уже не обойтись. Программы стали настолько сложными, что полностью удержать архитектуру в голове просто невозможно. Как писал МакКонелл «Главная цель программирования – управление сложностью».

Answer 4

[un1t]

> Были посты про то, что железо улучшается, а программы продолжают тормозить — не из-за этого ли?
> Десятки слоев, абстракций, отъедающие свои ресурсы.

Посмотрите доклады архитектуры highoad проектов. Тормозить могут три вещи — дисковые операции, база данных и сеть. ООП конечно проигрывает по скорости выполнения процедурному подходу, но этот проигрышь 0.00001% запроса к БД. Если программа тормозит, то не из за слоев абстракции, а вышеуказанных причин.

>MVC — круто, наворочено, универсально — но проигрывает по сравнению с тем же PHP по многим пунктам.

Тут либо неточность формулировки либо непонимание разницы. Нельзя сравнивать MVC и PHP, первое это шаблон проектирования, а второе это язык программирования. На PHP есть куча фреймворков придерживающихся MVC.

>Простой проект MVC — это около десятка папок, пять конфигов, куча контроллеров. Опять же — куда такие сложности?
> Для чего?

Это очень сильно упрощает жизнь даже в небольших проектах, в больших польза от этого растет экспотенциально.

>когда вы в этом успеваете разобраться? Сколько лет ковыряния нужно, чтобы досконально знать, что вызов вот
> этого приведет к этому, вызов того делает то, причем на пять слоев абстракций в глубину, и особенность
> вон того дает преимущество в этом.

Это зависит от опыта и сложности платформы, опытному программисту (5 лет коммерческой разработки на полную ставку) хватит от пары дней до пары недель чтобы начать выполнять новый проект на незнакомом фреймворке, месяца 3 чтобы уверенно себя чуствовать и 1-2 года, чтобы досканально разобраться во всех внутренностях.

Судя по году рождения, ты еще только начинаешь свой путь в программировании. Так что если пока в чем-то не удается разобраться это нормально. С опытом придет понимание.

>И как можно вникнуть в технологию, чтобы применять её на практике, если через пару лет появляется
> более новая технология или в корне меняется старая и надо снова рыться, снова изучать и т.п.

Новые технологии принципиално оличающиеся от всех предыдущих появляются редко, если вообще появляются. Все новые технологии основанны на предыдущем опыте. Например новомодная MongoDB которой лишь предстоит стать мэйнстримом основана на JavaScript и JSON, а эти технологии знакомы любому веб-разработчику. Другой пример новомодных NoSQL технологий — это key-storage хранилища например memcached и redis, любой кто работал с реляционными БД разберется в них за 5 минут. Конечно чтобы внкнуть в тонкости API и конфигурации нужно больше времени, но ничего сложного там нет.

Answer 5

[vsespb]

Не парьтесь. ИМХО в современном мире действительно существует тенденция использования библиотек, фреймворков, паттернов в тех случаях когда без них можно спокойно обойтись, и когда от них больше вреда чем пользы.

Это конечно не значит что все эти MVC не нужны. Они нужны — это уже описали в других ответах здесь. Просто изучая их и существующий код имейте ввиду что если вам кажется что этой библиотеке тут не место, возможно так и есть.

Comments

[vsespb]

Вот видите, количество минусов показывает как много людей считают, что для реализации любого функционала желательно, по возможности, подключить библиотеку, и хуже точно не будет.

[ofigenn]

Думаю, количество минусов, говорит лишь о том, что люди с Вами не согласны. Вы фантазер)

Answer 6

[codecity]

В глобальном смысле — это проблема нашей экономики. То, что вы описали — лишь частный случай: проекция нашей потребительской экономики на уровень IT. Аналогичную проблему можем наблюдать во всех сферах жизни: производятся одноразовые вещи с целью поиметь чем больше сиеминутной прибыли. Это относится и к софту, и к девайсам, и к одежде (тут есть понятие моды), и к предметам быта…

Понятно, что вовсе не обязательно выпускать новую версию Windows каждые 3 года. Смысл в этом только один — компания производитель хочет получить прибыль с новых продаж.

С другой стороны и сами пользователи подсели на эту «иглу» — им уже надоела программа, хотят новую версию. Кроме того, изменение одной программы (операционной системы или версии фреймворка) тянет за собой необходимость изменения всех других программ. Лишняя работа на пустом месте…

Та же беда и с фреймворками. В раскрутку фреймворка вкладывают много денег. Потом заказчик хочет, чтобы его проект был выполнен именно на том или ином фреймворке, т.к. его уже убедили в его «крутости».

Далее, по цепочке, умение использовать тот или иной фреймворк делает одних программистов конкурентноспособными, других не конкурентноспособными. Опять же, программист вынужден «обновлять свой мозг», чтобы получать деньги. Смысл только финансовый.

Конечно, в глобальном смысле «одноразовая экономика» — только вредит человечеству. Технологии-однодневки приводят к тому, что люди глубоко ничего не успевают изучить — только разобрался с ASP.Net WebForms, уже нужно изучать MVC и так далее.

Далее, здесь применима теория игр. Хотя все челочечество проигрывает от технологий-однодневок, на личном уровне это приносит прибыль (шкурный интерес).

Answer 7

[Борис Сёмов]

Фреймворки необходимы, как основа любого боле- менее сложного проекта.
Основные причины:
-Стандартизация и поддерживаемость кода, и уже это, практически всегда, важнее нескольких процентов оверхеда.
-Упрощение коллективной разработки.
-Повторное использование кода — отсутствие необходимости каждый раз реализовывать типичные вещи и отлаживать лишний код. Это касается и библиотек. Писать всё с 0, практически всегда, крайне неразумно. Кроме того, что заметно увеличиваются трудозатраты, так и качество в среднем падает(или трудозатраты растут уж совсем сильно — куда больше отладки и тестирования).
-Возможность генерации кода и.т.п., что помогает сильно ускорить разработку.

По поводу излишних абстракций, тормозов, технологий. Надо уметь выбирать подходящие к задаче и условиям её решения инструменты. Часто, бывает выгоднее создать более ресурсоёмкое приложение, чем оно могло бы быть, но быстрее. Это конечно неприятно и некрасиво, но это реалии нашей жизни.
Есть, конечно, и обратные примеры, где производительность и потребление ресурсов критично, необходимо вылизывать код по максимуму, но они встречаются кууууда реже, и в основном в довольно специфических областях.

> Как остаться нормальным программистом не на задворках, не потерять хватку и не теряться во всем этом?
Постоянно учиться и специализироваться в более узкой области. Это верно для любого специалиста, собственно, и с программированием прямо не связано…

Answer 8

[Пума Тайланд]

Только для того чтобы ускорить разработку и сделать её более правильной без излишний велосипедов и костылей.