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

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

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

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

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

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

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

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

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

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

• Найти новых разработчиков легко разгоняться, набирать скорость. Книга и образец CSLA app - отличные ресурсы, чтобы быстро освоиться.
• Структура валидации действительно мирового класса - и была «заимствована» для многих других проектов и технологий, не относящихся к 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 - это что угодно, кроме Серебряная пуля, он подходит для некоторых сценариев.

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

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

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

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

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

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

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

CSLA обеспечивает четкое разделение между вашим пользовательским интерфейсом, BusinessLogic и Persistance, и мы написали для них множество модульных тестов. Это может быть не строго TDD, потому что вы основываете его на дизайне пользовательского интерфейса, это не значит, что его нельзя тестировать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

//Энди

Мы широко используем 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 из списка, но прежде чем использовать его, изучите преимущества и убедитесь, что они действительно применимы. Сможет ли ваша команда правильно / последовательно реализовать это? Требуются удаленное взаимодействие и портальный танец?

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

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

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

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

Джон,

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

Крис

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

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

Плюсы:

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

Минусы

• Кода можно много поддерживать ¹
• Наверное, нужен генератор кода для эффективного использования
• Learning curve. The structure of CSLA objects are easy to grasp, but the caveats can create headaches.

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

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

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

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

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

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

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

Обновлено

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

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

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

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

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

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.

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

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

Спасибо -Blake Niemyjski (Автор Шаблоны 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 ... Я застрял с этими объектами списка.