Есть ли у кого-нибудь реальный опыт работы с CSLA?

Прежде чем конкретно ответить на ваш вопрос, я хотел бы высказать несколько мыслей. Подходит ли CSLA для вашего проекта? Это зависит. Я лично рассматривал бы CSLA для настольных приложений, которые не ценят модульное тестирование как высокий приоритет. CSLA отлично подходит, если вы хотите легко масштабироваться до n-уровневого приложения. CSLA имеет тенденцию к некоторому флэку, потому что он не позволяет проводить чистое модульное тестирование. Это правда, однако, как и все в технике, я считаю, что нет ни одного истинного пути . Модульное тестирование может быть не тем, что вы делаете для конкретного проекта. То, что работает для одной команды и одного проекта, может не работать для другой команды или другого проекта.

Существует также много заблуждений в отношении CSLA. Это не ORM. это не конкурент NHibernate (на самом деле использование бизнес-объектов CLSA & NHibernate в качестве доступа к данным очень хорошо сочетается). Он формализует понятие подвижного объекта .

1. Сколько людей используют CSLA?
Основываясь на форумах CSLA , я бы сказал, что существует довольно много проектов на основе CSLA. Честно говоря, я понятия не имею, сколько людей на самом деле используют его. Я использовал его в прошлом на двух проектах.

2. Какие есть плюсы и минусы?
Хотя это трудно обобщить в коротком списке, вот некоторые из pro/con's, которые приходят на ум.
Плюсы:

• Это легко получить новых разработчиков вверх ускорить. Книга и образец CSLA приложение-это большие ресурсы, чтобы войти в курс дела.
• Система валидации действительно мирового класса - и была "borrowed" для многих других проектов и технологий, не относящихся к CSLA.
• отмена N-го уровня в бизнес-объектах
• Изменение конфигурации линии для n-уровня масштабируемости (Примечание: даже не перекомпилировать надо)
• Ключевые технологии абстрагируются от кода "real". Когда было WCF введенный, он имел минимальное влияние на Код CSLA.


• Возможно совместное использование бизнес-объектов между windows и веб-проектами.
• CSLA способствует нормализации поведения , а не нормализации данных (оставляя базу данных для нормализации данных).

Аферы:

• Трудности при модульном тестировании
• Отсутствие разделения интересов (как правило, ваши бизнес-объекты имеют код доступа к данным внутри них).
• As CSLA способствует нормализации поведения , а не нормализации данных, и это может привести к появлению бизнес-объектов, которые называются одинаково, но имеют разные цели. Это может вызвать некоторую путаницу и ощущение, что вы не используете объекты повторно должным образом. Тем не менее, как только физиологический скачок сделан, он более чем имеет смысл - кажется неуместным структурировать объекты "old" способом.
• Это не "in fashion", чтобы строить приложения таким образом. Вы можете бороться, чтобы получить разработчиков, которые увлечены этой технологией.

3. После прочтения этой статьи действительно ли CSLA не вписывается в TDD?
Я не нашел эффективного способа сделать TDD с CSLA. Тем не менее, я уверен, что есть много более умных людей, чем я, которые могли бы попробовать это с большим успехом.

4. Какие у меня есть альтернативы?
Domain-Driven-Design получает большой толчок в данный момент (и по праву - это фантастика для некоторых приложений). Существует также ряд интересных паттернов, развивающихся с момента введения LINQ (и LINQ до SQL, Entity Framework и т. д.). Fowlers book PoEAA, подробно описывает множество шаблонов, которые могут подойти для вашего применения. Обратите внимание, что некоторые паттерны конкурируют (т. е. Active Record и Repository), и поэтому предназначены для использования в конкретных сценариях. Хотя CSLA точно не соответствует ни одному из паттернов, описанных в этой книге, он больше всего напоминает Active Record (хотя я чувствую, что это недальновидно утверждать, что он точно соответствует этому паттерну).

5. Если вы перестали его использовать или решили отказаться от него, то почему?
Я не полностью рекомендовал CSLA для моего последнего проекта, потому что я считаю, что объем приложения слишком велик для тех преимуществ, которые предоставляет CSLA.
Я бы не стал использовать CSLA в веб-проекте. Я чувствую, что есть другие технологии, которые лучше подходят для создания приложений в этой среде.

Таким образом, хотя CSLA-это что угодно , но не серебряная пуля, она подходит для некоторых сценариев.

Надеюсь, это поможет!

Прочитав все ответы, я заметил, что довольно много людей имеют некоторые неправильные представления о CSLA.

Во-первых, CSLA-это не ORM . Как я могу сказать это так определенно? Потому что Рокфорд Лхотка сам неоднократно заявлял об этом в интервью на подкастах .NET Rocks и Hanselminutes . Поищите любой эпизод, где Рокки брал интервью, и он изложит его в недвусмысленных выражениях. Я думаю, что это самый важный факт для понимания людей, потому что почти все неверные представления о CSLA проистекают из веры в то, что это ORM или попытки использовать его как один.

Как намекнул Брэд Лич в своем ответе, CSLA объектов моделируют поведение, хотя правильнее было бы сказать, что они моделируют поведение данных, поскольку данные являются их неотъемлемой частью. CSLA-это не ORM, потому что он полностью агностичен в отношении того, как вы говорите со своим хранилищем данных. Вы должны использовать какой-то уровень доступа к данным с CSLA, возможно, даже с ORM. (Я так и делаю. Теперь я использую Entity Framework, который прекрасно работает.)

Теперь перейдем к модульному тестированию. У меня никогда не было никаких трудностей с модульным тестированием моих объектов CSLA, потому что я не помещаю свой код доступа к данным непосредственно в мои бизнес-объекты. Вместо этого я использую некоторые вариации шаблона репозитория. Репозиторий потребляется CSLA, а не наоборот. Меняя местами поддельный репозиторий для моих модульных тестов и используя локальный портал данных, BOOM! все очень просто. (Как только Entity Framework позволит использовать POCOs, это будет еще чище.)

Все это происходит от осознания того, что CSLA-это не ORM. Он может потреблять ORM, но сам по себе не является таковым.

Овации.

UPDATE

Я решил сделать еще несколько замечаний.

Некоторые люди говорят, что CSLA-это многословие по сравнению с такими вещами, как LINQ-SQL и так далее. Но здесь мы сравниваем яблоки с апельсинами. От LINQ до SQL - это ORM. Он предлагает некоторые вещи, которые не делает CSLA, а CSLA предлагает некоторые вещи, которые не делает L2S, например интегрированную проверку и N-уровневую сохраняемость через различные удаленные порталы данных. На самом деле, я бы сказал, что последняя вещь, N-уровневая настойчивость, превосходит их всех для меня. Если я хочу использовать Entity Framework или LINQ - SQL через сеть, я должен поместить что-то вроде WCF между ними, и это чрезвычайно умножает работу и сложность до такой степени, что я думаю, что это гораздо более многословно, чем CSLA. (Теперь я поклонник WCF, REST и SOA, но используйте его там, где вам это действительно нужно, например, когда вы хотите предоставить услугу третьим лицам. Для большинства приложений line-of-business это действительно не нужно, а CSLA-лучший выбор.) На самом деле, с последней версией CSLA , Rocky предоставляет WCFDataPortal, который я использовал. Это прекрасно работает.

Я поклонник SOLID , TDD и других современных принципов разработки программного обеспечения и использую их везде, где это практично. Но я думаю, что преимущества CSLA перевешивают некоторые возражения этих ортодоксий, и в любом случае мне удалось заставить CSLA работать довольно хорошо (и легко) с TDD, так что это не проблема.

Да, я (ГМ, мы) широко использовал его для моделирования нашей логики бизнес-процессов, которая в основном была связана с формами данных в приложении windows forms. Приложение представляло собой торговую систему. CSLA предназначен для того, чтобы быть на этом уровне чуть ниже UI.

Если вы думаете о своем стандартном сложном приложении line-of-business, у вас может быть форма со многими полями, много правил для этих полей (включая правила проверки кросс-полей), вы можете вызвать модальный диалог для редактирования некоторого дочернего объекта, вы можете захотеть иметь возможность отменить такие диалоги и вернуться к предыдущему состоянию. CSLA поддерживает это.

Его минусы заключаются в том, что он имеет немного кривую обучения.

Главное, что нужно помнить, - это использовать CSLA для моделирования того, как пользователь взаимодействует с формами в некотором приложении. Самым эффективным способом для меня было разработать UI и понять его потоки, поведение и правила проверки перед построением объектов CSLA. У вас нет вашего дизайна CSLA objects drive UI.

Мы тоже нашли его очень полезным, чтобы иметь возможность использовать CSLA бизнес-объектов на стороне сервера, чтобы проверить объекты, отправленные от клиентов.

У нас также были встроенные механизмы для асинхронного выполнения валидации по отношению к веб-сервису (т. е. проверки диапазона кредитных лимитов контрагента по отношению к мастеру).

CSLA обеспечивает сильное разделение между вашими UI, BusinessLogic и Persistence, и мы написали массу юнит-тестов против них. Это может быть не совсем TDD, потому что вы управляете им из дизайна UI, но это не значит, что он не поддается тестированию.

Единственная реальная альтернатива-это создание собственной модели \ бизнес-объектов , но довольно скоро вы закончите реализацию функций, которые CSLA предлагает из коробки (INotifyPropertyChanged, IDataErrorInfo, PushState, PopState и т. д.)

У меня был опыт работы с ним несколько лет назад. Это блестящая архитектура, но очень сложная, трудная для понимания или изменения, и она решает проблему, которую большинство из нас, разрабатывающих веб-приложения, не обязательно имеют. Он был разработан больше для windows приложений на основе и обработки многоуровневых отмен, с большим акцентом на транзакционную логику. Вы, вероятно, услышите, как люди говорят, что, поскольку веб-приложения являются запросом-ответом на уровне страницы, это неуместно, но с веб-приложениями в стиле AJAX, возможно, этот аргумент не так уж много воды утекает.

У него очень глубокая объектная модель, и может потребоваться некоторое время, чтобы действительно обернуть ваш мозг вокруг нее. Конечно, за несколько лет многое может измениться. Мне было бы интересно услышать и другие недавние мнения.

Учитывая все обстоятельства, это был бы не мой первый выбор архитектуры.

Я использовал CSLA для одного проекта, и он отлично работал и делал вещи намного проще и аккуратнее.

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

//andy

В защиту CSLA, хотя я согласен со многими замечаниями, которые были сделаны, в частности, в отношении юнит-тестирования...

Моя компания широко использовала его для приложения ввода данных Windows Forms, с высокой степенью успеха.

• Он обеспечивал из коробки функциональность, которую у нас не было ни времени, ни опыта, чтобы написать самим.
• Он стандартизировал все наши бизнес-объекты, что упрощает техническое обслуживание и сокращает время обучения для наших новых разработчиков.

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

UPDATE: в дополнение к этому мы все еще используем его для нашего приложения windows forms, но эксперименты с его использованием для других приложений, таких как веб-сайты, показали, что это, возможно, слишком громоздко, когда вам не нужно много его функциональности, и мы сейчас исследуем более легкие варианты для этих сценариев.

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

Еще пара вопросов:

Мне не нужен дорожный блок между моим кодом и фреймворком .NET, который является тем, что этот фреймворк чувствовал для меня. У меня был ограниченный выбор объектов списка, в то время как я просто должен был игнорировать объекты расширенного списка в фреймворке .NET.

Совершенно нелепо, что у нас были эти списки только для чтения, а затем и не только для чтения. Итак, если бы мне пришлось добавить элемент в список, я должен был воссоздать весь list...are вы серьезно?

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

Почему я не могу просто создать экземпляр объекта? В конечном итоге мы создаем статические методы, которые создают экземпляр объекта и передают его back...are вы шутите?

Проверьте исходный код фреймворка, и мне кажется, что он сильно зависит от кода отражения.

Причины для использования csla:

• прямой фреймворк .net слишком силен для вас.

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

  1. Мне не нужен блок дороги между моим кодом и .NET framework...I я застрял с этими объектами списка.

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

Мы думали, что интерфейс проверки действительно поможет нам обеспечить соблюдение бизнес-правил, но он плохо работал с WCF и сериализацией (мы все еще застряли на версии 2.0.3.0, поэтому все могло измениться).

Наша компания практиковала CSLA в некоторых своих проектах, и некоторые из унаследованных проектов остаются CSLA. Другие проекты отошли от него, потому что CSLA нарушил простое и ясное правило OOP: принцип единой ответственности.

CSLA объекты являются самоподдерживающимися, например, они извлекают свои собственные данные, они управляют своим собственным поведением, они спасают себя. К сожалению, это означало, что ваш средний объект CSLA имеет по крайней мере три обязанности-представление модели домена, содержащей бизнес-правила и содержащей определение доступа к данным (а не DAL, или реализация доступа к данным, как я ранее stated/implied) все одновременно.

Не берите CSLA из списка, но прежде чем использовать его, изучите преимущества и убедитесь, что они действительно применимы. Сможет ли ваша команда правильно / последовательно реализовать его? Удаленное управление и портальный танец необходимы?

Я думаю, что помимо всех теоретических размышлений, все дело в коде clean/maintainable/extendable/testable, следующем основным проверенным шаблонам.

Я подсчитал строки кода, необходимые в конкретной области проекта, преобразованного из CSLA. Между всеми различными объектами CSLA (readonly+editable+root + list combinations) и их сохраненными процессорами потребовалось около 1700 строк, в то время как реализация репозитория Linq2SQL + заняла 180 строк. Версия Linq2SQL состояла в основном из сгенерированных классов,которые вашей команде не нужно использовать для понимания книги. И да, я использовал CodeSmith для создания частей CSLA, но теперь я верю в код DRY с одиночными битами ответственности, и реализация CSLA теперь выглядит для меня как вчерашний герой.

В качестве альтернативы я хотел бы предложить рассмотреть Linq2Sql / Entity Framework/NHibernate в сочетании с шаблонами репозитория и UnitOfWork. Взгляните на http://www.codeplex.com/backgroundmotion

Ваше здоровье!

Я новичок в CSLA, но я понимаю концепции, и я уже понимаю, что это не инструмент ORM, так что хватит бить в этот чертов барабан, ребята. Есть функции CSLA, которые мне нравятся, но с их помощью я чувствую себя немного так, как будто за занавесом находится волшебник. Я думаю, если вы не против не знать о том, как это работает, то вы можете использовать объекты, и они работают нормально.

Существует большая кривая обучения для начинающих, и я думаю, что это было бы очень полезно, имея 5-15 мин. видео, как у Microsoft есть для изучения основ. Или как насчет выпуска сопутствующей книги с кодом вместо того, чтобы выпускать код и тратить месяцы на то, чтобы выпустить книгу? Просто сказал мистер Лохтка... Мы начали собирать наши вещи еще до выхода книги, и я все время боролся. Но, как я уже сказал, Я здесь новичок.

Мы использовали CSLA. Мы сделали так, чтобы наши объекты соответствовали их форме, а затем использовали 10% из того, что предлагал фреймворк. Отмена уровня объекта? Я им не пользовался. NTier гибкость? Я им не пользовался. Мы закончили тем, что написали достаточно кода бизнес-правил, и я думал, что единственное, что мы получаем от CSLA, - это сложность. Некоторые разработчики "long in the tooth", которые знают фреймворк, использовали его как свой молоток, потому что у них был гвоздь, который нужно было ударить. CSLA был в их поясе, и я думаю, что многие сторонники фреймворка тоже видят вещи с этой точки зрения.

Я думаю, что наши опытные разработчики счастливы, потому что все это имеет смысл для них. Я думаю, что если в вашей организации нет начинающих программистов, и вам, ребята, скучно писать эффективные и простые объекты POCO с хорошо сформированными шаблонами, тогда идите на это. Используйте CSLA.

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

Мы широко используем CSLA. Есть несколько преимуществ; Во-первых, я считаю, что каждый бизнес-разработчик должен прочитать книгу Рокки Лхотки о программировании бизнес-объектов. Я лично обнаружил, что это входит в топ-3 лучших книг по программированию. CSLA-это фреймворк, основанный на этой книге, и использование его дает вашему проекту доступ к очень высокоуровневым функциям, таким как N-level undo, правила проверки и архитектура масштабируемости, предоставляя вам подробную информацию. Заметьте, я сказал "providing", а не "hiding". Я обнаружил, что лучшая часть CSLA-это то, что позволяет вам понять, как все эти вещи реализуются вплоть до исходного кода, не заставляя вас воспроизводить их самостоятельно. Вы можете использовать столько или несколько функций, сколько вам нужно, но я обнаружил, что, оставаясь верным шаблонам дизайна фреймворка, он действительно избавляет вас от неприятностей. --Байрон

Многие люди рекомендуют использовать генерацию кода с CSLA. Я бы рекомендовал проверить наш набор поддерживаемых шаблонов, так как они значительно увеличат ваш ROI.

Спасибо - Блейк Нимийски (автор шаблонов CodeSmith CSLA )

Я использую CSLA с vb5, когда это была скорее коллекция шаблонов, чем фреймворк. С введением of.NET, CSLA превратилось в полномасштабную структуру,которая пришла с большой кривой обучения. Однако CSLA обращается ко многим вещам, которые все бизнес-разработчики обычно пишут сами в какой-то момент (в зависимости от объема проекта): логика проверки, логика аутентификации, функциональность отмены, грязная логика и т. д. Все эти вещи вы получаете бесплатно из коробки в одном красивом фреймворке.

Как утверждали другие, будучи фреймворком, он заставляет разработчиков писать бизнес-логику аналогичным образом. Это также заставляет вас обеспечить уровень абстракции для вашей бизнес-логики, так что не использование фреймворка UI, такого как MVC, MVP, MVVM, становится не столь важным.

На самом деле, я бы сказал, что причина, по которой так много этих паттернов UI так раздуты сегодня (в мире Microsoft), заключается в том, что люди так долго делали вещи невероятно неправильно (т. е., используя DataGrids в вашем UI, разбрызгивая вашу бизнес-логику повсюду. тиск-тиск). Правильно спроектируйте свой средний уровень (бизнес-логику) с самого начала, вы можете повторно использовать свой средний уровень в любом пользовательском интерфейсе. Форма Выигрыша, ASP.NET/MVC, WCF Обслуживание, WPF, Silverlight**, Windows Обслуживание, ....

Но помимо этого, огромным выигрышем для меня была его встроенная способность масштабироваться. CSLA использует шаблон прокси-сервера, который настраивается через ваш конфигурационный файл. Это позволяет вашим бизнес-объектам совершать удаленные вызовы с сервера на сервер, не записывая ни одного фрагмента кода. Добавление новых пользователей в вашу систему? Нет проблем, разверните свои бизнес-объекты CSLA на новом сервере приложений, внесите изменения в запись файла конфигурации и BAM!! Мгновенная масштабируемость должна быть удовлетворена.

Сравните это с использованием DTO, хранением вашей бизнес-логики на клиенте (независимо от того, какой клиент это может быть) и необходимостью писать каждый из ваших собственных методов CRUD в качестве методов обслуживания. YIKES!!! Я не говорю, что это плохой подход, но я бы не хотел этого делать. Не тогда, когда есть структура, которая по существу делает это за меня.

Я собираюсь повторить то, что другие люди сказали в том, что CSLA-это NOT-это ORM. CSLA вынуждает вас снабжать свои бизнес-объекты данными. Им все равно, где вы получаете свои данные. Вы можете использовать ORM для предоставления данных вашим бизнес-объектам. Вы также можете использовать raw ADO.NET, другие сервисы (RESTFUl, SOAP), excel электронные таблицы, я могу продолжать работать здесь.

Что касается вашей поддержки TDD, я никогда не пытался использовать этот подход и с CSLA. Я использовал подход, при котором моделирую свой средний уровень (бизнес-объекты ala) с использованием диаграмм классов и последовательностей, чаще всего позволяя диктовать варианты использования, экран и/или дизайн процесса. Возможно, немного старой школы, но UML всегда очень хорошо служил мне в моих усилиях по проектированию и разработке. Я успешно проектировал и разрабатывал очень большие и масштабируемые приложения, которые все еще используются сегодня. И пока WCF RIA не созреет, я буду продолжать использовать CSLA..

** с некоторыми обходными путями

Я использую CSLA в качестве основы бизнес-объекта для проекта среднего размера. Фреймворк прошел долгий путь от VB6 дней и предлагает необычайную гибкость и функциональность "out of the box". Мобильные смарт-объекты CSLA значительно упрощают разработку UI. Однако я согласен с другими, что это не правильный инструмент для каждой ситуации. Там определенно есть какие-то накладные расходы, но и много энергии. Лично я с нетерпением жду возможности использовать CSLA Light с Silverlight.

Плюсы:

• Технология передачи данных agnostic ¹
• Большая установочная база и это FREE!!
• Стабильная и логическая структура
• Код доступа к данным может быть в ваших объектах или в отдельном assembly
• Проверка и авторизация свойств и объектов

Аферы

• Код может быть много для поддержания ²
• Вероятно, нужен генератор кода для эффективного использования
• Кривая обучения. Структуру объектов CSLA легко понять, но предостережения могут вызвать головную боль.

Я использовал CSLA.NET в нескольких проектах сейчас, это было наиболее успешно в приложении windows forms, которое имеет богатые возможности привязки данных (которые не имеют приложения asp.net).

Это основная проблема-поддержка TDD, как люди указывали, это связано с поведением черного ящика для функций Dataportal_XYZ, и это неспособность позволить нам издеваться над объектами данных. Были предприняты усилия для решения этой проблемы с учетом того, что это наилучший подход

Я парень с номером PHP. Когда мы начали создавать сравнительно крупномасштабные приложения с PHP, я начал исследовать множество прикладных фреймворков и ORMs по существу в мире PHP, а затем в Java и .NET. Причина, по которой я также рассматривал фреймворки Java и .NET, состояла не в том, чтобы слепо использовать любой фреймворк PHP, а в том, чтобы сначала попытаться понять, что на самом деле происходит и какие существуют архитектуры корпоративного уровня.

Поскольку я не использовал CSLA в реальном приложении, я не могу комментировать его плюсы и минусы, но могу сказать, что Lhotka-один из редких мыслителей - я не говорю просто эксперт-в области архитектуры программного обеспечения. Хотя название Domain Driven Design придумано Эриком Эвансом -кстати, его книга тоже замечательная, и я смиренно советую ее прочитать - Lhotka применяла domain driven design в течение многих лет. Сказав это, что бы вы ни думали о его структуре, извлеките пользу из его глубоких идей в этой области.

Вы можете найти его выступления на dotnetrocks.com/archives.aspx и видео с dnrtv.com/archives.aspx (поиск Lhotka).

@Byron Какие еще две книги вам понравились?

В последний раз я пытался использовать CSLA в каменном веке, когда было VB6. Оглядываясь назад, я понимаю, что было бы более эффективно, если бы я использовал генерацию кода. Если у вас нет эффективных инструментов генерации кода и стратегии их использования в вашем рабочем процессе, вам следует избегать таких фреймворков, как CSLA, иначе функции, которые вы получаете от CSLA, не смогут компенсировать количество времени, которое вы тратите на написание n строк кода в таблице, n строк кода в столбце и т. д.

Джон,

У нас есть команды, работающие в CSLA от 2 до 3.5, и мы нашли отличный способ обеспечить согласованную структуру, чтобы все разработчики были "doing it the same way". Это здорово, что большая часть кода с низким значением генерируется, и мы знаем, что когда мы запускаем модульные тесты, они работают из коробки для всех CRUD вещей. Мы обнаруживаем, что наш TDD действительно входит в рефакторинг, который мы делаем для проектирования, и CSLA не мешает нам делать все это.

Крис

Я использовал его для одного проекта пару лет назад. Но когда проект был закончен, я не мог никому рассказать, что сделал для меня CSLA. Конечно, я унаследовал его от своих классов. Но я смог удалить это наследование почти из всех классов без какой-либо реструктуризации. Нам не нужны были эти N-уровневые штуки. Отмена n-уровня была настолько медленной, что мы не могли ее использовать. Поэтому я думаю, что в конце концов это только помогло нам смоделировать наши классы.

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

Я хотел использовать его,но мой тогдашний ведущий разработчик был слишком увлечен идеей 'magic'...

CSLA - это лучший фреймворк приложения, который существует. Рокки LHotka-очень, но очень умный парень. Он пишет историю разработки программного обеспечения, как Мартин Фаулер, Дэвид С. Платт, но мои любимые писатели-род Стивенс, Мэтью mcDonalds Джефф Левинсон теарон Уиллис и Луис Дэвидсон псевдоним dr sql. :-) Плюсы: все шаблоны дизайна применяются. Минусы: трудно учиться, и мало образцов.