Основное веб-приложение моей компании - это крик для отличного набора библиотек, чтобы сделать его каким-то удобным и масштабируемым, и один из моих коллег предложил CSLA. Поэтому я купил книгу, но как:
программисты больше не читают книги
Я хотел оценить мнение сообщества SOFlow об этом.
Итак, вот мои вопросы:
Прежде чем я конкретно отвечу на ваш вопрос, я хотел бы немного высказать свои мысли. Правильно ли CSLA для вашего проекта? Это зависит. Я бы лично рассмотрел CSLA для настольных приложений, которые не оценивают модульное тестирование как высокий приоритет. CSLA отлично подходит, если вы хотите легко масштабировать приложение n-уровня. CSLA имеет тенденцию получать некоторую флэку, потому что она не позволяет проводить чистое модульное тестирование. Это правда, однако, как ничто в технологии, я считаю, что нет ни одного True Way. Тестирование модулей может не быть чем-то, что вы предпринимаете для конкретного проекта. То, что работает для одной команды и одного проекта, может не работать для другой команды или другого проекта.
Есть также много заблуждений относительно CSLA. Это не ORM. он не является конкурентом NHibernate (фактически используя CLSA Business Objects и NHibernate, так как доступ к данным очень хорошо сочетается). Он формализует концепцию мобильного объекта.
1. Сколько людей использует CSLA?
Основываясь на CSLA Forums, я бы сказал, что существует множество проектов на основе CSLA. Честно говоря, я не знаю, сколько людей действительно использует это. Я использовал его в прошлом по двум проектам.
2. Каковы плюсы и минусы?
Хотя в кратком списке трудно подвести итог, вот некоторые из про/кон, которые приходят на ум.
Плюсы:
Минусы:
3. После прочтения этого CSLA действительно не подходит для TDD?
Я не нашел эффективного способа сделать TDD с CSLA. Тем не менее, я уверен, что есть намного более умные люди, чем я, которые, возможно, пробовали это с большим успехом.
4. Каковы мои альтернативы?
Домен-Driven-Design получает большой толчок в настоящий момент (и по праву - это фантастично для некоторых приложений). Существует также ряд интересных шаблонов, разработанных при внедрении LINQ (и LINQ to SQL, Entity Framework и т.д.). Книга Фаулеров PoEAA, подробно описывает многие шаблоны, которые могут быть подходящими для вашего приложения. Обратите внимание, что некоторые шаблоны конкурируют (например, Active Record and 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, но сам он не один.
Приветствия.
Я думал, что сделаю еще несколько комментариев.
Некоторые люди говорят, что 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, так что это не проблема.
Да, я (um, we) широко использовал его для моделирования логики бизнес-процессов, которая была в основном форматами данных в приложении форм Windows. Приложение было торговой системой. CSLA предназначен для того, чтобы быть на этом уровне чуть ниже пользовательского интерфейса.
Если вы думаете о своем стандартном комплексном бизнес-приложении, у вас может быть форма со многими полями, многие правила для этих полей (включая правила проверки поперечного поля), вы можете вызвать модальный диалог для редактирования некоторого дочернего объекта, вы можете захотеть иметь возможность отменить такие диалоги и вернуться к предыдущему состоянию. CSLA поддерживает это.
Это означает, что у него немного кривая обучения.
Главное, что нужно помнить, - использовать CSLA для моделирования взаимодействия пользователя с формами в каком-либо приложении. Наиболее эффективным способом для меня был дизайн пользовательского интерфейса и понимание его потоков, поведения и правил проверки до создания объектов CSLA. Не используйте объекты интерфейса CSLA для создания пользовательского интерфейса.
Мы также обнаружили, что очень полезно иметь возможность использовать серверные объекты бизнес-объектов CSLA для проверки объектов, отправленных с клиентов.
У нас также были встроены механизмы для асинхронной проверки валидации против веб-службы (т.е. проверки диапазона кредитного лимита контрагента против ведущего).
CSLA обеспечивает сильное разделение между вашим пользовательским интерфейсом, BusinessLogic и Persistance, и мы написали нагрузку единичных тестов против них. Это может быть не строго TDD, потому что вы управляете им из дизайна пользовательского интерфейса, что не означает, что он не тестируется.
Единственной реальной альтернативой является создание вашей собственной модели\бизнес-объектов, но довольно скоро вы в конечном итоге реализуете функции, которые CSLA предлагает из коробки (INotifyPropertyChanged, IDataErrorInfo, PushState, PopState и т.д.).
У меня был опыт работы с ним несколько лет назад. Это блестящая архитектура, но очень сложная, трудная для понимания или изменения, и она решает проблему, которую большинство из нас разрабатывает веб-приложения не обязательно. Он был разработан больше для приложений на базе Windows и обработки многоуровневых отступлений, с большим вниманием к транзакционной логике. Вероятно, вы услышите, как люди говорят, что, поскольку веб-приложения являются запросом-ответом на уровне страницы, это неуместно, но с веб-приложениями в стиле AJAX, возможно, этот аргумент не содержит столько воды.
У этого есть очень глубокая объектная модель, и это может занять некоторое время, чтобы действительно обернуть вокруг вас мозг. Конечно, многое может измениться через несколько лет. Мне было бы интересно услышать другие недавние мнения.
Все рассмотренные вещи, это не мой первый выбор архитектуры.
Я использовал CSLA для одного проекта, и он отлично работал и делал вещи намного проще и аккуратнее.
Вместо того, чтобы ваша команда писала бизнес-объекты в своем собственном личном стиле, мы знаем, что для них существует общий стандарт.
//Энди
В защиту CSLA, хотя я согласен со многими комментариями, которые были сделаны, в частности, для тестирования единицы...
Моя компания широко использовала приложение для ввода данных Windows Forms с высокой степенью успеха.
В целом я бы сказал, что любые проблемы, которые он вызвал, были более чем оправданы преимуществами.
ОБНОВЛЕНИЕ. В дополнение к этому мы все еще используем его для нашего приложения форм Windows, но эксперименты с его использованием для других приложений, таких как веб-сайты, показали, что это, пожалуй, громоздко, когда вам не нужна большая часть его функций, и мы теперь исследуют более легкие варианты веса для этих сценариев.
Я присоединился к команде, в которой CSLA является обязательным. Мы не используем удаленный портал данных, и это единственная причина, по которой я могу согласиться на использование этой структуры. Я никогда не покупал идею CSLA, поэтому, может быть, поэтому у меня нет ничего, кроме проблем с ней, извините.
Пара проблем:
Мне не нужен дорожный блок между моим кодом и платформой .NET, что и представляло мне эта структура. У меня был ограниченный список объектов списка, в то время как мне просто пришлось игнорировать объекты с богатым списком в .NET framework.
Ii совершенно нелепо, что у нас были эти списки только для чтения, а затем списки, не предназначенные для чтения. Поэтому, если бы мне пришлось добавить элемент в список, мне пришлось воссоздать весь список... вы серьезно?
Затем csla хочет управлять моим состоянием объекта, которое прекрасно, но ничего действительно не отображается. Иногда я хочу изменить состояние объекта вручную, а не набирать его снова, что похоже на то, что хочет csla. Я, в основном, создаю много свойств, чтобы выставлять опции. Csla не думал, что у меня должен быть прямой доступ.
Почему я не могу создать экземпляр объекта? Мы создаем статические методы, которые копируют объект и передают его обратно... вы издеваетесь надо мной?
Проверьте исходный код рамки, и он выглядит тяжелым для кода отражения.
Причины использования csla:
ваши разработчики не приправлены и не могут понять концепцию шаблонов, тогда csla в значительной степени будет иметь на одной странице.
Мы начали использовать CSLA, потому что мы думали, что это поможет с нашим слоем модели. Был своего рода overkill, и в основном все, что мы используем сейчас, это класс SmartDate, только потому, что мы уже связаны с библиотекой.
Мы полагали, что интерфейс проверки действительно поможет нам внедрить бизнес-правила, но он не очень хорошо работает с WCF и сериализацией (мы все еще придерживаемся версии 2.0.3.0, поэтому все могло измениться).
Наша компания практиковала CSLA в некоторых своих проектах, а некоторые из старых проектов остаются CSLA. Другие проекты отошли от него, потому что CSLA нарушила простое и простое правило ООП: принцип единой ответственности.
Объекты CSLA являются самоподдерживающимися, например. они получают свои собственные данные, они управляют своим поведением, они спасают себя. К сожалению, это означало, что ваш средний объект CSLA имеет как минимум три обязанности - представление модели домена, содержащее бизнес-правила и содержащее определение доступа к данным (а не DAL или реализацию доступа к данным, как я уже говорил/подразумевал) все в одном время.
Не принимать CSLA из списка, но перед его использованием изучите преимущества и убедитесь, что они действительно применяются. Смогут ли ваша команда правильно/последовательно внедрить его? Нужны ли удаленные и портальные танцы?
Я думаю, что за пределами всех теоретических размышлений речь идет о чистом/поддерживаемом/расширяемом/тестируемом коде после основных проверенных шаблонов.
Я подсчитал строки кода, необходимые в определенном домене проекта, преобразованного из CSLA. Между всеми объектами CSLA (только для чтения + редактируемые комбинации + root + list) и их сохраненными процессами потребовалось около 1700 строк, а реализация Linq2SQL + Repository - 180 строк. Версия Linq2SQL состояла в основном из сгенерированных классов, которые вашей команде не нужны для понимания книги. И да, я использовал CodeSmith для генерации частей CSLA, но теперь я верю в DRY-код с единичными битами ответственности, а реализация CSLA теперь выглядит мне как вчерашний герой.
В качестве альтернативы я хотел бы предложить изучить Linq2Sql/Entity Framework/NHibernate в сочетании с шаблонами репозитория и UnitOfWork. Посмотрите http://www.codeplex.com/backgroundmotion
Ура!
Мы используем CSLA уже более пяти лет, и мы считаем, что он отлично работает для построения бизнес-приложений. В сочетании с генерированием кода вы можете создавать бизнес-объекты за относительно короткий промежуток времени и фокусировать свои усилия на мясе приложения.
Мы широко используем CSLA. Существует несколько преимуществ; во-первых, я считаю, что каждая линейка бизнес-разработчиков должна читать книгу Роки Лхотки по программированию Business Objects. Я лично нашел его в моих лучших 3 лучших книгах по программированию. CSLA - это основа, основанная на этой книге, и ее использование дает вашему проекту доступ к очень высокоуровневым функциям, таким как n-level undo, правила проверки и архитектура масштабируемости, предоставляя детали для вас. Заметьте, я сказал "предоставление", а не "скрытие". Я обнаружил, что лучшая часть CSLA заключается в том, что вы понимаете, как все эти вещи реализованы вплоть до исходного кода, не заставляя вас воспроизводить их самостоятельно. Вы можете использовать столько или несколько функций, сколько вам нужно, но я обнаружил, что, оставаясь верным шаблонам проектирования фреймворка, он действительно избавляет вас от неприятностей. --Byron
Я новичок в CSLA, но я понимаю понятия, и я уже понимаю, что это не инструмент ORM, так что перестаньте избивать этих чертовых барабанщиков. Есть особенности CSLA, которые мне нравятся, но использование их немного похоже на волшебника за занавеской. Я думаю, если вы не возражаете, не зная о том, как это работает, вы можете использовать объекты, и они работают нормально.
Существует большая кривая обучения для новичков, и я думаю, что это принесло бы большую выгоду, имея 5-15 минут. таких как Microsoft, для изучения основ. Или как насчет выпуска сопутствующей книги с кодом вместо того, чтобы освободить код и взять месяцы, чтобы получить книгу? Просто скажи, господин Лохтка... Мы начали строить свои вещи перед книгой, и я боролся все время. Но, как я уже сказал, я новичок в этом.
Мы использовали CSLA. Мы сделали наши объекты подходящими для своей формы, а затем использовали 10% того, что предлагалось. Отменить уровень объекта? Не использовал его. Гибкость NTier? Не использовал его. Мы закончили тем, что написали достаточно кода бизнес-правил, который, как я думал, единственное, что мы выбрали из CSLA, было сложностью. Некоторые "длинные в зубе" разработчики, которые знают рамки, использовали его в качестве своего молотка, потому что у них был гвоздь, который нуждался в ударе. CSLA была на их поясе, и я думаю, что многие сторонники структуры видят вещи с этой точки зрения тоже.
Я думаю, наши опытные разработчики счастливы, потому что все это имеет для них смысл. Я думаю, если у вашей организации нет программистов-новичков, и вам, ребятам, надоедает, создавая эффективные и простые объекты POCO с хорошо сформированными шаблонами, а затем идите на это. Используйте CSLA.
Я использую CSLA в качестве инфраструктуры бизнес-объектов для проекта среднего размера. Структура прошла долгий путь от дней VB6 и предлагает исключительную гибкость и функциональность "из коробки". Мобильные интеллектуальные объекты CSLA значительно упрощают разработку интерфейса. Однако я согласен с другими, что это не правильный инструмент для каждой ситуации. Конечно, есть некоторые накладные расходы, но также много власти. Лично я с нетерпением жду использования CSLA Light с Silverlight.
1 Хорошо, потому что технологии доступа к данным никогда не остаются надолго.
2 Это улучшилось с последними версиями фреймворка.
Я использую CSLA с vb5, когда это было больше из коллекции шаблонов, чем это была структура. С введением .NET CSLA превратилась в полномасштабную инфраструктуру, в которой была сложная кривая обучения. Тем не менее, CSLA рассматривает многие вещи, которые все разработчики бизнеса склонны писать в какой-то момент (в зависимости от области проекта): логика проверки, логика аутентификации, функциональность отмены, грязная логика и т.д. Все эти вещи вы получаете бесплатно из в одной красивой структуре.
Как утверждали другие, будучи основой, он заставляет разработчиков писать бизнес-логику аналогичным образом. Это также заставляет вас обеспечить уровень абстракции для вашей бизнес-логики, чтобы не использовать инфраструктуру пользовательского интерфейса, такую как MVC, MVP, MVVM, становится не столь важным.
На самом деле, я бы сказал, что причина, по которой столь многие из этих шаблонов пользовательского интерфейса настолько раздуты сегодня (в мире Microsoft), состоит в том, что люди делали вещи невероятно неправильно так долго (то есть, используя DataGrids в вашем UI, повсюду разбрызгивая вашу бизнес-логику. Tisk tisk). Создайте свой средний уровень (бизнес-логику) с самого начала, вы можете повторно использовать свой средний уровень в ЛЮБОМ интерфейсе. Win Form, ASP.NET/MVC, WCF Service, WPF, Silverlight **, Windows Service,...
Но помимо этого огромная прибыль для меня была встроенной способностью масштабироваться. CSLA использует шаблон прокси, который настраивается через ваш файл конфигурации. Это позволяет вашим бизнес-объектам делать удаленные вызовы с сервера на сервер без необходимости писать один лиз кода. Добавление большего количества пользователей в вашу систему? Нет проблем, разверните бизнес-объекты CSLA на новый сервер приложений, внесите изменения в файл конфигурации и BAM!! Требуется мгновенная масштабируемость.
Сравните это с использованием DTO, сохраняя свою бизнес-логику на клиенте (любой клиент, который может быть), и должен писать каждый из ваших собственных методов CRUD в качестве методов обслуживания. YIKES!!! Не сказать, что это плохой подход, но я бы не хотел этого делать. Не там, где есть основа, чтобы сделать это для меня.
Я собираюсь повторить то, что говорили другие люди в том, что CSLA НЕ является ORM. CSLA заставляет вас предоставлять ваши бизнес-объекты данные. Им все равно, где вы получаете свои данные. Вы можете использовать ORM для доставки бизнес-объектов с данными. Вы также можете использовать raw ADO.NET, другие сервисы (RESTFUl, SOAP), Excel таблицы, я могу продолжать здесь.
Что касается вашей поддержки TDD, я никогда не пробовал использовать этот подход с CSLA. Я применил подход, когда я моделирую средний уровень (бизнес-объекты ala) с использованием диаграмм классов и последовательностей, чаще всего позволяя использовать сценарий использования, экрана и/или процесса. Возможно, немного старая школа, но UML всегда хорошо меня вдохновлял в моих проектах и разработках. Я успешно разработал и разработал очень большие и масштабируемые приложения, которые все еще используются сегодня. И пока WCF RIA не созреет, я продолжу использовать CSLA..
** с некоторыми работами вокруг
Многие люди рекомендуют использовать Code Generation с CSLA. Я бы рекомендовал проверить наш набор поддерживаемых шаблонов, так как они значительно повысят рентабельность инвестиций.
Спасибо -Blake Niemyjski (автор CodeSmith CSLA Templates)
Я использовал его для проекта пару лет назад. Но когда проект был завершен, я не мог сказать никому, что CSLA для меня сделала. Конечно, я унаследовал его классы. Но я смог удалить это наследование практически со всех классов без реструктуризации. Мы не использовали материал N-Tier. Отмена n-уровня была настолько медленной, что мы не могли ее использовать. Поэтому, я думаю, в конце это помогло нам моделировать наши классы.
Сказав это, другие команды начали использовать его (после ужасной попытки команды создать свою собственную инфраструктуру). Поэтому там должно быть что-то стоящее, потому что они все умнее меня!
Я парень PHP. Когда мы начали создавать сравнительно крупные приложения с PHP, я начал изучать множество фреймворков приложений и ORM по существу в мире PHP, а затем в Java и .NET. Причина, по которой я также рассматривал платформы Java и .NET, заключалась не в том, чтобы слепо использовать любую фреймворк PHP, но сначала попытайтесь понять, что действительно происходит, и какие архитектуры уровня предприятия существуют.
Поскольку я не использовал CSLA в реальном мире, я не могу комментировать его плюсы и минусы, но я могу сказать, что Лхотка - один из редких мыслителей - я не говорю просто экспертное программное обеспечение Область архитектуры. Хотя имя Domain Driven Design придумано Эриком Эвансом - так же хорошо, как его книга, и я смиренно советую ее прочитать. Лхотка много лет применяла дизайн, ориентированный на домен. Сказав это, что бы вы ни думали о его рамках, пользуйтесь его глубокими идеями в этой области.
Вы можете найти его переговоры на dotnetrocks.com/archives.aspx и видео с dnrtv.com/archives.aspx(поиск Lhotka).
@Byron Какие две другие книги вам нравятся?
Джон
У нас есть команды, работающие в CSLA от 2 до 3.5, и нашли это отличным способом обеспечения согласованной структуры, поэтому все разработчики "делают это одинаково". Замечательно, что большая часть кода с низким значением генерируется, и мы знаем, когда мы запускаем модульные тесты, которые они работают из коробки для всего материала CRUD. Мы находим, что наш TDD действительно приходит с рефакторингом, который мы делаем для проектирования, и CSLA не мешает нам делать что-либо из этого.
Крис
Я в последний раз пытался использовать CSLA в каменные годы VB6. Оглядываясь назад, это было бы более эффективно, если бы я использовал генерацию кода. Если у вас нет эффективных инструментов генерации кода и стратегии их установки в рабочий процесс, вам следует избегать таких фреймворков, как CSLA, иначе функции, которые вы получаете от CSLA, не будут компенсировать количество времени, затрачиваемого на чтение n строк кода на таблицу, n строк кода на столбец и т.д.
Я использовал CSLA.NET в нескольких проектах сейчас, он был наиболее успешным в приложении для форм Windows, которое обладает богатыми привязками к привязке данных (в приложении asp.net их нет).
Основная проблема заключается в поддержке TDD, о которой говорили люди, из-за поведения в черном ящике для функций Dataportal_XYZ и невозможности насмехаться над объектами данных. Были предприняты усилия для решения этой проблемы, поскольку this является наилучшим подходом
Я хотел использовать его, но у моего тогдашнего разработчика была идея слишком много "волшебства"...
CSLA - лучшая инфраструктура приложения, которая существует. Рокки Лхотка очень, но очень умный парень. Он пишет историю разработки программного обеспечения, как Мартин Фаулер, Дэвид С Платт, но моими любимыми писателями являются Род Стивенс, Мэтью Макдональдс Джефф Левинсон и Уиллис и Луис Дэвидсон.:-) Плюсы: применяются все шаблоны проектирования. Минусы: трудно учиться, и несколько образцов.