Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
по-моему, "правильный" ответ очевиден...
хотя второй вариант не исключает первого, а просто дополняет его..
хотя второй вариант не исключает первого, а просто дополняет его..
Такой как django
Мне кажется, не все варианты.
А если философия в том, что можно совершенно по разному построить приложение?
ИМХО без философии хорошего проекта не бывает, другое дело что идеи использования бывают разными.
А если философия в том, что можно совершенно по разному построить приложение?
ИМХО без философии хорошего проекта не бывает, другое дело что идеи использования бывают разными.
Хороший фреймворк должен быть написан.
Я выбрал второй вариант, так как перегиб в сторону первого(Он должен содержать инструменты...) может сделать фреймворк слишком абстрактным и не применимым для конкретных задач. А перегиб в сторону третьего(Должен навязывать философию использования...) варианта сделает фреймворк слишком негибким. Лучшее - враг хорошего.
А я думаю, каждый фреймворк хорош по-своему
А мне кажется 3 вариант имеет ввиду не жесткость и негибкость, а то что определенное действие может быть выполнено только одним способом.
И при этом не ограничивается каличество самих действий (чтобы можно было сделать все что угодно). Философия должна помогать понимать код стороннему рабработчику и не плодить велосипеды.
Но в критических ситуациях должна быть возможность смело плюнуть на философию.
И при этом не ограничивается каличество самих действий (чтобы можно было сделать все что угодно). Философия должна помогать понимать код стороннему рабработчику и не плодить велосипеды.
Но в критических ситуациях должна быть возможность смело плюнуть на философию.
В третьем варианте мне слово "навязывать" не понравилось, по этому выбрал второй.
2 вариант.
Навязывать философию разработки, но предоставлять выбор для реализации.
Всегда должна оставаться гибкость в этапах разработки.
Как пример можно привести управляемый/не управляемый код в C#.
Навязывать философию разработки, но предоставлять выбор для реализации.
Всегда должна оставаться гибкость в этапах разработки.
Как пример можно привести управляемый/не управляемый код в C#.
Он должен идеально подходить под задачу - на данный момент для меня это GWT.
А вообще(не Web) фреймворк должень быть с малой core максимально гибким а-ля Spring, ну например не Rails/Django - а Merb/Pylons.
А вообще(не Web) фреймворк должень быть с малой core максимально гибким а-ля Spring, ну например не Rails/Django - а Merb/Pylons.
Новичку фреймворк не нужен. Новичок сам должен написать один-два-много фреймворков, чтобы разобраться в принципах, получить опыт и понять, что не следует изобретать велосипеды.
А опытному разработчику нужен фреймворк, который достаточно мощен, чтобы решать разные задачи, гибок, чтобы решать нестандартные задачи, подробен, чтобы избавить от рутины и изобретения велосипедов, и нравится, чтобы с ним приятно было работать.
Не стоит забывать, что каждой задаче - свой инструмент.
Третий вариант - однозначно полезен в крупных проектах и больших командах.
Первый (первые два - чем они отличаются) - на нестандартных задачах, в руках умелых программистов...
Третий вариант полезен, если хорошо подходит проекту, если все накладные расходы (резервирования памяти, обращения к базам и т.п.) оказываются затребованы и оправданы.
Первые два - если фреймворк надо задействовать частично, раздёргать на компоненты и модули, выбросить всё лишнее.
И наконец, третий вариант хорош, если надо быстро включиться в работу и некогда экспериментировать и выбирать, что будет, если сделать так, а не иначе.
А опытному разработчику нужен фреймворк, который достаточно мощен, чтобы решать разные задачи, гибок, чтобы решать нестандартные задачи, подробен, чтобы избавить от рутины и изобретения велосипедов, и нравится, чтобы с ним приятно было работать.
Не стоит забывать, что каждой задаче - свой инструмент.
Третий вариант - однозначно полезен в крупных проектах и больших командах.
Первый (первые два - чем они отличаются) - на нестандартных задачах, в руках умелых программистов...
Третий вариант полезен, если хорошо подходит проекту, если все накладные расходы (резервирования памяти, обращения к базам и т.п.) оказываются затребованы и оправданы.
Первые два - если фреймворк надо задействовать частично, раздёргать на компоненты и модули, выбросить всё лишнее.
И наконец, третий вариант хорош, если надо быстро включиться в работу и некогда экспериментировать и выбирать, что будет, если сделать так, а не иначе.
Второе, конечно, идеально. Но, с другой стороны, Django есть хороший фреймворк, хотя он больше к третьему варианту подходит.
Использую Tapestry для построения веб-части. Устраивает компонентный подход, довольно логичное построение контроллеров, отделение представление от контроллера. Для бизнес-уровня (в терминах J2EE) использую Spring. Устраивает удобный IoC-контейнер, набор фабрик для подключения Hibernate, обработки транзакций, интерцептирования и т.д. Тем более что Spring нативно подключается к Tapestry.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Каков должен быть, на Ваш взгляд, хороший framework?