Что такое CSLA Framework и как его использовать?

Question

Что такое CSLA Framework и как его использовать?

Answer 1

Мои мнения из моего опыта с базой кода 1.7M LOC:

1. CSLA предназначен для среды распределенных приложений / баз данных. Вот почему основным бизнес-объектом является и выполняется все, например, сохранение собственной информации. Объект (и все, что удаленно связано с его состоянием) предназначен для сериализации, отправки в другое приложение и / или на сервер данных и работы.
2. Если вышеперечисленное не является проблемой, которую вам нужно решить, CSLA излишне, большое время. Наша команда разработчиков сожалеет о приверженности CSLA.
3. Жонглировать всеми шарами CSLA в сложном оконном интерфейсе очень сложно. У нас есть экраны с несколькими вкладками (которые могут, в свою очередь, открывать подэкраны), которые, если вы не выполните последовательность ввода данных «слева направо, сверху вниз» и часто нажимаете кнопку «Сохранить», заканчивают тем, что вводят и / или извлекают неполные данные в / из базы данных; или вообще сбросив данные, которые вы только что ввели. Да, виноваты наши оригинальные кодеры, но так же и CSLA ... Просто кажется, что существует так много движущихся частей, которые позволяют включать, контролировать и координировать функции CSLA. Это все равно, что иметь дело со всеми циферблатами и переключателями истребителя, когда все, что вам действительно нужно, это что-то более похожее на Cessna 152.
4. Вы напишите много пользовательского кода, чтобы включить функции CSLA. Например, CSLA никогда не следует путать с инструментами реляционного сопоставления объектов (ORM), такими как Hibernate и Entity Framework. Наши методы SAVE () нетривиальны, как и тривиальные.
5. Поощрение использования генераторов кода усугубляет проблемы. Мы использовали CodeSMith для генерации классов из таблиц данных. Таким образом, мы получаем код, имеющий соответствие таблицы 1-1 классу c #. Поэтому вы должны написать весь код для обработки dataStore для ваших «реальных» объектов.
6. Хранение / извлечение данных очень неэффективно с CSLA. Из-за монолитной, центрированной парадигмы BusinessObject «делает все и все знает» объекты в конечном итоге выполняют выборку и создание экземпляров данных по одному объекту за один раз. Коллекции составных объектов значительно усложняют проблему. Один «get this object» всегда приводит к каскаду отдельных выборок данных (по одной или более для каждого отдельного объекта) для создания экземпляров всей цепочки наследования и составных отношений. Это известно как «проблема запроса N + 1». Да, и выборка данных ВСЕГДА приводит к созданию нового объекта, даже если мы только обновляем существующий. Неудивительно, что наши более сложные экраны FUBAR.

Это позволяет вам проектировать ваше приложение с основополагающими объектно-ориентированными принципами и хорошим разделением проблем.

Да и нет. В основном нет.

BusinessObject управляет собственным хранением данных. Это анти разделение интересов.

«Это позволяет вам…», ну, да, так же как и пустой экран текстового редактора, но не заставляет и не поощряет вас, как, например, инфраструктура MVC.NET. ИМХО, CLSA обеспечивает абсолютно нулевую выгоду, гарантируя, что код, который вы разрабатываете с ним, следует «твердым принципам ОО». На самом деле кодеры со слабыми навыками OO (большинство, по моему опыту) действительно будут выделяться при использовании CSLA! Горе программисту по обслуживанию.

CSLA является потомком для принципа твердого объекта предпочитает композицию наследованию. Код CLSA не проверяется. Поскольку унаследованная инфраструктура BusinessObject есть, делает и нуждается во всем, все сразу и каждый раз, маловероятно, что вы сможете получить много тестового покрытия. Вы не можете получить по кусочкам, потому что все тесно связаны. Фреймворк не поддается инъекции зависимостей. Это железный занавес кода.

Ваш код будет трудно отлаживать. Стеки вызовов становятся очень глубокими, и когда вы, так сказать, приближаетесь к центру солнца, все превращается в отражение - «какие методы * & ^ # только что были вызваны ???» И ты просто заблудился. период.

РЕДАКТИРОВАТЬ 7 марта 2016

Что еще я могу добавить к оригинальному сообщению? Две вещи, возможно:

Во-первых, он чувствует , как будто у CSLA есть обещание. Если бы мы знали, как совмещать все эти движущиеся части. Но CSLA настолько загадочна, что даже то, что мы сделали правильно, со временем искажается. ИМХО без очень сильной CSLA в команде, где любая реализация обречена. Без энергичного «открытого источника» технических ссылок, обучения и сообщества это безнадежно. Почти десятилетие наш код CSLA, по моему окончательному анализу, просто увеличивает технический долг.

Во-вторых, вот мой недавний комментарий:

Наша сложность часто не вписывается в инфраструктуру CSLA поэтому мы пишем вне рамок. Это и дешевая рабочая сила приводит к безудержные нарушения SRP и я ударил кирпичные стены управления динамическим применение правила, например. Затем CSLA родительская / дочерняя инфраструктура распространяет проверку составного объекта, но мы не всегда хотим с / п отношения, поэтому мы пишем больше проверки и храним код. Поэтому сегодня наша реализация CSLA противоречива и запутана. Рефакторинг на больше-лучше CSLA будет иметь глубокие эффекты домино. Итак, после этого Первоначальная инъекция CSLA по существу прекращена.

конец Редактировать

Answer 2

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

Я настоятельно рекомендую вам прочитать книгу CSLA Рокки Лотки под названием Expert C # 2008 Business Objects. Это не только научит вас основам, но и научит хорошим принципам архитектуры программного обеспечения.

Вы можете взять книгу здесь на Amazon

Answer 3

В ответ на @radarbob https://stackoverflow.com/a/10922373/261363, надеюсь, я не пожалею об этом и начну пламенную войну.

Наша команда разрабатывала несколько LOB-приложений с CSLA. Из моего опыта написания приложений для «зеленого поля» с CSLA и поддержки существующего кода, вот мои ответы на ваши вопросы.

1. BO не предполагает, что он выполняет свою собственную персистентность данных, у вас будет фабрика, которая будет обрабатывать всю персистентность данных, например, используя ORM для сопоставления с моделями, которые позже будут сохранены.

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

3. У вас есть BO -> Портал -> Фабрики, которые не должны быть очень сложными. Существующие примеры CSLA в значительной степени объясняют, что происходит на каждом уровне.

4. CLSA никогда не следует путать с ORM

5. Как и следовало ожидать, бизнес-объект редко отображается на одну таблицу и поэтому требует немного работы при сохранении. В случае, если они сопоставлены с одной таблицей, вы используете что-то вроде AutoMapper для сопоставления вашего BO с вашим POCO в 1 строке.

6. Посмотрите на CSLA Commands, также ничто не мешает вам держать ваш BO таким маленьким или большим, как вы хотите, если вы помните, что они не совпадают с POCO, которые вы сохраните.

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

В какой-то момент я смог легко сохранить часть моих BO в MongoDB, поэтому приложение работало на гибридной базе данных MSSQL и MongoDB без необходимости даже изменять одну строку кода в моих бизнес-объектах, все, что мне нужно было сделать, это обновить фабрики для использования Mongo вместо текущей ORM.

Надеюсь, это справедливо решит все ваши вопросы,

Привет

Answer 4

Предлагаю прочитать страницу Что такое CSLA? и просмотреть сайт часто задаваемых вопросов CSLA .NET .

Для получения последней опубликованной информации ознакомьтесь с Using CSLA 4 ebook series .

Answer 5

CSLA: масштабируемая логическая архитектура на основе компонентов

Параграф в двух словах, описывающий CSLA для меня с веб-сайта, был таким:

CSLA .NET позволяет создавать объектно-ориентированный бизнес-уровень, который абстрагирует и инкапсулирует вашу бизнес-логику и данные. Эта среда обеспечивает бесперебойную работу ваших бизнес-объектов со всеми технологиями интерфейса .NET, включая WinRT XAML, WPF, ASP.NET MVC, веб-формы ASP.NET, WCF, службы asmx, Windows Phone 7, Silverlight, Windows Workflow и Windows Forms.

Почему вы можете использовать это:

Управление бизнес-правилами. Как только вы изучите систему бизнес-правил, она обеспечит способ применения бизнес-логики в аккуратном пакете. Если у вас есть объект с дочерними объектами, который должен сообщить о валидации на самый родительский уровень, есть способ справиться с этим. (см. http://www.lhotka.net/weblog/CSLA4BusinessRulesSubsystem.aspx для получения дополнительной информации о системе правил)

У вас есть бизнес-объекты, которые необходимо поддерживать для отмены N-уровня? CSLA BusinessBase имеет встроенную систему управления свойствами (например, свойства зависимостей) для таких функций, как N-Level Undo (фактически она полностью реализована). (Это также связано с управлением бизнес-правилами. Вы можете запустить проверку при изменении основного свойства, или вы можете изменить свойство на основе значения другого свойства.)

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

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

CSLA, при правильной архитектуре, поддается тестированию. Мы используем шаблон репозитория, чтобы заменить действительный dal на фиктивный слой и протестировать как по спецификации (используя NUnit / SpecFlow), так и в единичном режиме, когда это необходимо.

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

Учитывая все обстоятельства, CSLA может быть не для вас. Как указали другие, читайте сайт и книги (особенно Expert C # 2008 Business Objects.) Задавайте вопросы, поскольку сообщество CSLA стремится давать качественные советы.

Answer 6

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

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