Прочитав все ответы, я заметил, что довольно много людей имеют некоторые неправильные представления о CSLA.
Во-первых, CSLA не является ORM . Как я могу сказать это так определенно? Потому что Рокфорд Лхотка сам много раз заявлял об этом в интервью на подкастах .NET Rocks и Hanselminutes . Ищите любой эпизод, где Рокки давал интервью, и он изложит это недвусмысленно. Я думаю, что это самый важный факт, который люди могут понять, потому что почти все неправильные представления о CSLA вытекают из веры в то, что это ORM, или в попытке использовать его как единое целое.
Как отметил Брэд Лич в своем ответе, объекты CSLA моделируют поведение, хотя, возможно, было бы точнее сказать, что они моделируют поведение данных, поскольку данные являются для них неотъемлемыми. CSLA - это не ORM, потому что он абсолютно независим от того, как вы общаетесь с вашим хранилищем данных. Вы должны использовать некоторый уровень доступа к данным с CSLA, возможно, даже ORM. (Да. Теперь я использую Entity Framework, который прекрасно работает.)
Теперь перейдем к юнит-тестированию. У меня никогда не было проблем с модульным тестированием моих объектов CSLA, потому что я не помещаю свой код доступа к данным непосредственно в свои бизнес-объекты. Вместо этого я использую некоторые варианты шаблона хранилища. Репозиторий используется CSLA, а не наоборот. Путем замены поддельного репозитория для моих модульных тестов и использования локального портала данных, BOOM! все просто. (Как только Entity Framework разрешит использование POCO, это станет еще чище.)
Все это происходит от осознания того, что CSLA не является ORM. Он может потреблять ORM, но сам по себе он не один.
Приветствие.
UPDATE
Я думал, что сделаю еще несколько комментариев.
Некоторые люди говорят, что 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, так что это не проблема.