2009-08-05 2 views

ответ

11

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

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

You can grab the book here on Amazon

+0

ли это поддерживается структура. И каково было бы мое решение использовать эту структуру. – Greens

+1

Это поддерживается Rocky и поддерживается очень хорошо. Есть место для сообщения об ошибках, и на них часто реагируют быстро. –

+16

легко? могу я процитировать вас на этом? – D3vtr0n

1

CSLA подробно описана here. Новый book - отличная отправная точка. Как отличный комплимент этой книге я бы рекомендовал проверить наш CSLA 3.8 templates. Rocky рекомендует использовать генератор кода, и у нас есть ведущий набор шаблонов, который поможет вам быстро и быстро запустить вас.

Благодаря -Blake Niemyjski (автор CodeSmith CSLA Templates)

66

Мои мнения из моего опыта ж/LOC кодовой базы: 1,7 М

  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-all-and-know-all, объекты в конечном итоге выполняют выборку и экземпляр данных с использованием одного объекта в момент времени. Коллекции композитных объектов значительно осложняют проблему. Единый «получить этот объект» всегда приводит к каскаду отдельных выборок данных (один или несколько для каждого отдельного объекта), чтобы создать целые наследования целых цепочек отношений &. Его называют «проблемой запроса N + 1». О, и выборка данных ALWAYS приводит к созданию нового объекта, даже если мы только обновляем существующий. Неудивительно, что наши более сложные экраны - FUBAR.

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

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

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

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

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

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

EDIT 7 Mar 2016

Что еще понимание можно добавить после того, как исходное сообщение? Две вещи, возможно:

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

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

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

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

+17

Жаль, что я не смог бы проголосовать за это 1000 раз. CSLA, безусловно, является наихудшей структурой, с которой я когда-либо испытывал неудовольствие от работы. Вероятно, это будет полезно для тривиальных распределенных программ. Но, как вы сказали, серьезная работа требует инструментов, которые раскрывают власть, а не ограничивают вас. Все деловоеобъект вещь действительно самое худшее. Он заставляет каждый класс BO унаследовать один абстрактный объект. И способ, которым он это делает (через generics), полностью закручивает вашу способность наследовать бизнес-объекты. Это действительно ужасный каркас. –

+2

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

+2

Я полностью согласен с Кристианом. Если ваши бизнес-объекты сконструированы таким образом, который требует отдельных корневых объектов, на которые ссылаются другие корневые объекты, вы делаете что-то неуместно. У меня были очень большие деревья объектов, которые загружаются из одного запроса в базу данных, возвращая несколько наборов результатов. Средство для создания кодового словаря будет плохо работать. В нашем случае я создал DSL, который позволил нам сгенерировать наши бизнес-объекты из нескольких таблиц или сохраненных процессов, а также указать, какой тип объекта он и разрешения на него. Это ускорило разработку примерно на 300%. –

3

Я предлагаю чтение What is CSLA? страницу и просматривать CSLA .NET FAQ site.

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

+0

CSLA .NET переехал в GitHub пару лет назад - теперь на главной странице находится http://cslanet.com –

3

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

Абзац в двух словах, что описанной CSLA мне с веб-сайта был таков:

CSLA .NET позволяет создавать объектно-ориентированный бизнес который абстрагирует и инкапсулирует вашу бизнес-логику и данные. Эта инфраструктура обеспечивает бесперебойную работу ваших бизнес-объектов со всеми технологиями интерфейса .NET, включая WinRT XAML, WPF, ASP.NET MVC, ASP.NET Web Forms, 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 может и не быть для вас. Как указывали другие, прочитайте сайт и книги (особенно Business C# Business Objects). Задавайте вопросы, поскольку сообщество CSLA имеет тенденцию давать качественные рекомендации.

+1

Практически неважно, если вы изменили свой счет с дружественного OCD 999 (во время голосования) до этой уродливой задницы 1009. – daniloquio

3

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

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

  1. БО не предполагают, чтобы сделать это самостоятельно сохранение данных, вы будете иметь завод, который будет обрабатывать все данные послесвечения, например, с помощью ORM для сопоставления моделей, которые в дальнейшем сохраняются.

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

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

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

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

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

В проекте мы работали над нами, где могли легко протестировать БО, чтобы убедиться в правильности бизнес-логики. Из-за прекрасного разделения проблем мы проверили наши Заводы в изоляции, чтобы убедиться, что бизнес-объекты будут сохранены соответственно.

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

Надежда это решает все ваши очки на справедливой основе,

С уважением

Смежные вопросы