Если вы можете позволить себе лицензию LLBLGen, сделайте это.
Мне серьезно не нравится синтаксис запросов LINQ, тем более я работаю с ним (хотя я ЛЮБЛЮ связанные с ним возможности языка, такие как методы расширения и деревья выражений).
Сначала я любил, как и все, но не знал, будет ли [[where employee.Name.StartsWith ("John Smit")]] в этом поставщике XYZ LINQ выполняться в операторе SQL или в LINQ to Objects (после SQL возвращает все результаты), и то, будет ли [[user.Roles.Contains (role)]] вообще работать или нет, является большим шагом позади.
LLBLGen может сделать удаление всех элементов без загрузки их так же просто, как
MyEntityCollection.DeleteAll( new MyEntity {Condition = value} );
Это довольно просто, и мне это нравится. Вы получаете ленивую загрузку, и вы устанавливаете активную / глубокую загрузку по умолчанию и / или для каждого запроса, используя Prefetch API. Вы можете создавать и динамически (и легко) создавать любой фильтр / сортировку / загрузку на бесконечных уровнях. Это очень мило.
Есть только две проблемы, связанные с LLBLGen: во-первых, это цена, которую не все компании хотели бы заплатить, особенно учитывая шумиху над альтернативами Microsoft. Во-вторых, соглашение об именах, хотя и стандартное в теориях СУБД), такое как PredicateFactory вместо «где» или «filter» и Prefetch вместо глубокой загрузки и даже SortExpression вместо orderby, все это немного пугает разработчика, работающего с ним в первую очередь. времена, но вскоре вы научитесь любить их, учитывая силу и легкость, которые они дают. Говорят о поддержке POCO в LLBLGen 3.0. Я не могу сказать об этом, потому что я не знаю.
Теперь, когда я больше не работаю в компании, которая использует LLBLGen, компания использует LINQ to SQL главным образом потому, что она «проверена» во многих проектах без больших сбоев (в отличие от EF 1, в котором отсутствуют даже функции LINQ в LINQ to SQL). и имеет очень плохую производительность и может быть весьма ограничивающим в продвинутом отображении - что должно быть лучше для!) Я использовал оба в этой компании и ненавидел обоих. Решением для новых проектов остается LINQ to SQL, и мы делаем все возможное, чтобы преодолеть его ограничения. Этот веб-сайт StackOVerflow сам работает поверх него !!! Вы можете обойти это, чтобы выполнить SEMI-POCO (вам все еще нужно использовать некоторые связанные с L2S типы, когда дело доходит до ассоциаций).
Я также делаю небольшие проекты дома. Поскольку у меня больше нет лицензии LLBLGen, я решил изучить NHibernate и использовать его вместе с Fluent NHibernate и LINQ To NHibernate. Благодаря этому я узнал, что NHibernate ОЧЕНЬ силен. Это изменило то, как я работаю, благодаря некоторым функциям, таким как автоматическое обновление схемы БД (я почти никогда не трогал D при ее использовании). Иногда не хватает поставщика LINQ (в проекте NHibernate Contrib), но есть неопубликованный исходный код самого NHibernate, в котором содержится лучший поставщик LINQ (еще не пробовал). «Сеанс» в NHibernate имеет проблемы, когда вы занимаетесь веб-разработкой, аналогичной тем, которые связаны с DataContext в L2S или ObjectContext в EF (LLBLGen не страдает от этого благодаря самосопровождаемым сущностям).
Самой большой проблемой, с которой я столкнулся в NHibernate, была способность находить информацию. Слишком много частей, которые должны быть собраны определенным образом, и не так много указаний, может включать в себя расширенную информацию как для отображения, так и для запросов. Если бы у меня не было друга (Tuna Toksoz, @tehlike on twitter), который оказался коммиттером в исходном коде проекта NHibernate, у меня действительно были бы серьезные проблемы.
Мораль, которую я выучил, заключалась в следующем: если вы хотите что-то, что просто работает и немного базовое, используйте Linq To Sql или SubSonic, если вы хотите что-то посередине, и ваша производственная среда может позволить себе BETA .NET-версию (данный golive существует), используйте Entity Framework 4.0, если вы хотите что-то очень мощное и можете позволить себе трудный процесс обучения, переходите на NHibernate, И, ЛУЧШЕЕ ИЗ ВСЕХ, если вы можете позволить себе LLBLGen, ИСПОЛЬЗУЙТЕ ЕГО.