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

Основное веб-приложение моей компании требует отличного набора библиотек, чтобы сделать его каким-либо образом поддерживаемым и масштабируемым, и один из моих коллег предложил CSLA. Итак, я купил книгу, но как:

программисты больше не читают книги

Я хотел узнать мнение сообщества SOFlow об этом.

Итак, вот мои вопросы:

  1. Как люди могут использовать CSLA?
  2. Каковы плюсы и минусы?
  3. Неужели CSLA не вписывается в TDD?
  4. Какие у меня есть альтернативы?
  5. Если вы прекратили его использовать или отказались от него, почему?

Ответов (23)

Решение

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

Есть также много заблуждений относительно CSLA. Это не ORM. он не является конкурентом NHibernate (фактически, использование CLSA Business Objects и NHibernate, поскольку доступ к данным очень хорошо сочетается друг с другом). Формализует концепцию мобильного объекта .

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

2. Какие плюсы и минусы?
Хотя трудно подвести итог в кратком списке, вот некоторые из плюсов и минусов, которые приходят на ум.
Плюсы:

  • Новых разработчиков легко освоить. Книга CSLA и пример приложения - отличные ресурсы для ускорения.
  • Структура валидации действительно мирового класса - и была «заимствована» для многих других проектов и технологий, не относящихся к CSLA.
  • n-Level Undo в ваших бизнес-объектах
  • Изменение строки конфигурации для масштабируемости n-уровня (Примечание: даже перекомпиляция не требуется)
  • Ключевые технологии абстрагируются от «реального» кода. Когда был представлен WCF, он оказал минимальное влияние на код CSLA.
  • Вы можете делиться своими бизнес-объектами между окнами и веб-проектами.
  • CSLA способствует нормализации поведения, а не нормализации данных (оставляя базу данных для нормализации данных).

Минусы:

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

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

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

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

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

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

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

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

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

//Энди

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

Я думаю, что помимо теоретических размышлений, все дело в чистом / поддерживаемом / расширяемом / тестируемом коде, который следует базовым проверенным шаблонам.

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

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

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

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

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

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

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

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

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

ОБНОВИТЬ

Я подумал, что сделаю еще несколько комментариев.

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

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

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

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

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

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

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

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

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

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

** с некоторыми решениями

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

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

Минусы в том, что у него есть некоторая кривая обучения.

The key thing to remember is to use CSLA to model how a user interacts with forms on some application. The most efficient way for me was to design the UI and understand it's flows, behaviour and validation rules before building the CSLA objects. Don't have your CSLA objects drive UI design.

We also found it very useful to be able to use CSLA business objects server side to validate objects sent from clients.

We also had built in mechanisms to perform validation asynchronously against web service (i.e. checking the credit limit range of a counterparty against a master).

CSLA enforces a strong seperation between your UI, BusinessLogic and Persistance and we wrote a load of unit tests against them. It may not be strictly TDD because you are driving it from UI design, that doesn't mean it isn't testable.

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

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

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

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

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

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

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

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

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

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

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

В целом я бы сказал, что любые проблемы, которые это вызвало, были более чем устранены преимуществами.

ОБНОВЛЕНИЕ: в дополнение к этому мы все еще используем его для нашего приложения Windows Forms, но эксперименты с его использованием для других приложений, таких как веб-сайты, показали, что это, возможно, слишком громоздко, когда вам не нужна большая часть его функций, и сейчас мы исследуем более легкие варианты для этих сценариев.

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

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

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

Мы широко используем CSLA. Есть несколько преимуществ; Во-первых, я считаю, что каждый разработчик направления бизнеса должен прочитать книгу Рокки Лхотка по программированию Business Objects. Я лично обнаружил, что он вошел в тройку моих лучших книг по программированию. CSLA - это структура, основанная на этой книге, и ее использование дает вашему проекту доступ к очень высокоуровневым функциям, таким как n-уровневая отмена, правила проверки и архитектура масштабируемости, при этом предоставляя вам подробную информацию. Заметьте, я сказал «обеспечение», а не «сокрытие». Я обнаружил, что лучшая часть CSLA - это то, что вы понимаете, как все эти вещи реализованы вплоть до исходного кода, не заставляя вас воспроизводить их самостоятельно. Вы можете использовать столько функций, сколько вам нужно, но я обнаружил, что, оставаясь верным шаблонам проектирования фреймворка, это действительно убережет вас от неприятностей. - Байрон

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

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

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

@Byron Какие две другие книги тебе понравились?

Джон,

У нас есть команды, работающие над CSLA с 2 по 3.5, и мы сочли его отличным способом предоставить согласованную структуру, чтобы все разработчики «делали это одинаково». Замечательно, что большая часть низкокачественного кода генерируется, и мы знаем, что когда мы запускаем модульные тесты, они сразу работают со всеми CRUD-материалами. Мы обнаруживаем, что наш TDD действительно входит в рефакторинг, который мы проводим при разработке, и CSLA не мешает нам делать что-либо из этого.

Крис

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

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

Плюсы:

  • Независимость от информационных технологий 1
  • Большая база для установки, и это БЕСПЛАТНО!
  • Стабильная и логичная структура
  • Код доступа к данным может находиться в ваших объектах или в отдельной сборке
  • Проверка и авторизация свойств и объектов

Минусы

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


Я не уверен в дизайне, основанном на тестах. Я не занимаюсь модульным тестированием или дизайном, основанным на тестировании (позор мне), поэтому я не знаю, отличаются ли модульные тесты от TDD, но я знаю, что самая последняя версия фреймворка поставляется с модульными тестами.


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

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

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

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

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

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

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

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

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

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

Пара вопросов:

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

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

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

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

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

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

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

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