Pull to refresh

Comments 15

Ну просто CAB сам по себе и всякие Software Factories, доступные на CodePlex'е довольно сложны для большинства разработчиков, поэтому хоорших специалистов, да еще и таких, которые могли бы доходчиво объяснить что это и с чем его едят, тоже очень мало (отсюда и шок при первом знакомстве… у всех у кого спрашивал, по крайней мере, тоже так было). Мало не только «у нас», но и «у них».
А вобще да, вещь полезная, сапортили как-то систему автоматизации документооборота с использованием CAB/SCSF, преимуществ в разработке масса.
— За статью спасибо, если решите еще что-либо писать на эту тематику, то было бы интересно почитать о связке Smart Client + WPF.
Как руки дойдут:) Обязательно напишу.
Ооой… Хорошо то как, благодать! После такой кучи статей о макворлде и рассказов про 911 увидеть большую и интересную по программированию! Уважили, батенька, спасибо большое!
Оно так получается, что если .net разработчик доходит до того, что ему нужны IoC-контейнеры, то, как правило, он пользуется чем-то типа StructureMap или Castle MicroKernel/Windsor Containers. Ну, сейчас еще Unity подтягивается. А вот CAB всегда был не более, чем design guide sample, как и все остальные AB.
Как правило, разработчик доходит до того, что ему нужен фреймворк, что ему программу надо писать быстро и надежно (особенно, когда требования неясны).

Что вы подразумеваете под design guide sample?
Приложение к patterns & practices — демонстрации решения программистских задач средствами .net.
Не знаю, как сейчас, но пару лет назад авторами делался особый акцент на том, что все это — не более, чем примеры для изучения, которые не обкатывались на масштабных системах и даже не разрабатывались для этого.
И, это плохо? Я не понимаю, что вы хотите сказать этим.
Нет, не плохо. Просто сопряжено с определенным риском, что используемый AB очень рано перестанет удовлетворять растущим требованиям. Но если границы проекта изначально очерчены, то AB может быть достаточным и даже идеальным выбором.

Т.е. AB — это как раз не для случаев, когда изначально не известно, до чего этот проект разрастется. Поэтому я и отдаю сразу предпочтение чему-то, у чего есть хорошая «кредитная история», серьезные отзывы от серьезных людей и т.д., а тут как раз все не в пользу AB.

Тут еще размышление — почему этим AB никаким образом не распространяются MS пусть если не в составе .NET Framework, то хотя бы как опция к Visual Studio. Вот ASP.NET MVC пошел в народ… А что, он реально сложнее этого же CAB? Вроде как нет…
Понял.

Что касается AB — я веду собственную кредитную историю:) На CAB-е сделал четыре проекта, поэтому никакого подозрения не возникает. Что касается опций к Visual Studio — а вы уверены, что это показатель? WPF тоже не сразу стал включатся в дистрибутив. Он точно так же крутился, вертелся, пока не был признан годным, хорошим, не получил хороших отзывов, пока люди не стали на нем проекты делать. А до этого он был точно такой же экспериментальщиной. Точно так же и с упомянутым вами MVC — здесь, я думаю, маркетинг давит — срочно нужны современные hi-end средства разработки веб-приложений.

Думаю, что с CAB-ом все более произаично — ошибки менеджмента. Сначала был CAB, разработчикам он понравился, но он работал через WinForms, а тут выходит WPF. Быстро сделали WPF-CAB, с поддержкой WPF контролов через WinFormsHost — не понравилось. Потом объявили об собственном каркасе, круче тока горы — проект Acropolis, но не доделали, бросили — опять что-то помешало, я уже не помню, что. Потом плюнули, все удалили, сделали Unity. Вот у него есть будущее, я считаю:)

Так что, время покажет. Я к тому, что проект должен варится, его должны использовать и давать фидбэк разработчикам — тогда у него есть все шансы стать общеиспользуемым. Нужны новаторы, которые не побоятся использовать экспериментальные технологии — в конце концов только так они перестают быть экспериментальными.
У меня есть опыт работы с User Interface AB. Вот после этого и осталось неприятное послевкусие… :)
Общая черта всех этих AB — это тесная связанность с соседями + иногда и со средствами разработки…

Спрашивается, какая связь между IoC и WinForms/WPF? Зачем?

Мне просто по душе юникс-подход, когда фреймворк строится из изолированных компонентов, каждый из которых выполняет свою задачу и не более. А уже на верхнем уровне могут быть другие компоненты, которые связывают все в кучу, расширяют IDE и т.д. Взять хоть WiX, хоть NHibernate и т.д. — на низком уровне это нечто + конфиг файл, а потом к нему идут всякие contributions, всякие визуальные средства и синтаксический сахар. Но ядро при этом никак не связано с contribs.

В этом случае фреймворк в бОльшей степени является инструментарием, чем архитектурным каркасом, как это заведено в AB. И, собссно, это их предназначение и не скрывается — ставь, читай design guide, и собирай приложение из готовых кирпичиков.
Хм. Определите, пожалуйста, архитектурный каркас?

Скажу вот что — OB является ядром CAB и может использоваться автономно. Я это показал в своей статье. Связи между IoC и WinForms в CAB-е в чистом виде нет, если только не рассматривать контрол WinForms как объект зависимости. WinForms в движке не более, чем средство визуализации. IoC используется для обеспечания loose coupling компонент приложения и для того, чтобы «склеить» компоненты движка. В конечном итоге, получился продукт, который позволяет программисту оперировать семантикой движка, крутится в его рамках, что, в свою очередь, позволяет ему сконцентрироваться на решении функциональных, а не инфраструктурных задач. Вот именно в этом фишка IoC.

Эх. Видимо, придется поскорее написать про CAB.
Каркас в данном случае — это когда скачиваешь, ставишь, запускаешь студию, выбираешь тип проекта и работаешь во вновь созданном солюшне с уже готовым дизайном.

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

Посмотрите на Enterprise Library и сравните его с Castle/Spring.NET.
Sign up to leave a comment.

Articles