Использование объектов Linq-to-SQL в вашем BLL или UI?

Question

У меня был клиент, который попросил совета при создании простого приложения WPF LOB на днях. Они в основном хотят приложение CRUD для базы данных, основной целью которого является учебный проект WPF.

Я также показал им Linq To SQL, и они были впечатлены.

Затем я объяснил, что, вероятно, не очень хорошая идея использовать эти объекты L2S напрямую из их кода BLL или UI. Вместо этого они должны рассмотреть что-то вроде шаблона Repository.

В этот момент я уже мог чувствовать сверхинженерные звонки тревоги, звучащие в их головах (и в некоторой степени и в моих). Им действительно нужна вся эта сложность для простого приложения CRUD? (Хорошо, он эффективно функционирует как учебный проект WPF для них, но давайте представим, что он превращается в «настоящее» приложение).

• Считаете ли вы когда-либо приемлемым использование сущностей L2S во всем приложении?
• Насколько сложно (исходя из опыта) рефакторинга использовать другую среду персистентности позже?

На мой взгляд, если уровень пользовательского интерфейса использует объекты L2S в качестве простого POCO (не затрагивая какие-либо специфические методы L2S), то в дальнейшем это будет действительно легко выполнить рефакторингом в случае необходимости.

Им нужен способ централизовать запросы L2S, поэтому необходим какой-то способ управления этим, даже если они действительно используют объекты L2S напрямую. Таким образом, мы уже продвигаемся к некоторым аспектам DAL / DAO / Repository.

Основная проблема с Repo, которую я вижу, - это проблема отображения между объектами L2S и некоторой моделью предметной области. И стоит ли это того? Вы получаете довольно много «бесплатно» на объектах L2S, которые, я думаю, будет трудно использовать, когда вы переходите на другую модель.

Мысли

Answer 1

Единственный существенный недостаток использования сущностей L2S - то, что ваш пользовательский интерфейс должен знать и привязываться к конкретным сущностям. Это означает, что ваш пользовательский интерфейс знает ваш уровень данных. Обычно это не очень хорошая идея. Вы действительно хотите многоуровневый подход ко всему, что может быть серьезным.

Тем не менее, вполне возможно использовать сами сущности LINQ-to-SQL в многоуровневой архитектуре без знания уровня данных: извлекать интерфейсы для сущностей и связываться с ними.

Имейте в виду, что все объекты L2S являются частичными классами. Создайте интерфейсы, которые отражают ваши сущности (Refactor => Extract Interface здесь ваш друг), и создайте частичные определения классов ваших сущностей, которые реализуют интерфейсы. Поместите сами интерфейсы (и только интерфейсы) в отдельный .DLL, на который ссылается ваш пользовательский интерфейс и бизнес-уровень. Пусть ваш бизнес-уровень и уровень данных принимают и испускают эти интерфейсы, а не конкретные версии. Вы даже можете иметь интерфейсы, реализующие INotifyPropertyChanging, поскольку объекты L2S сами реализуют эти интерфейсы. И все это работает персиково.

Тогда, когда / если вам нужна другая структура персистентности, вы не испытываете никакой боли в BL или UI, только в слое данных - именно там, где вы хотите.

Answer 2

Хранилища не имеют большого значения. Смотрите здесь для довольно хорошей обработки их использования в ASP.NET MVC:

http://nerddinnerbook.s3.amazonaws.com/Part3.htm

Answer 3

Считаете ли вы когда-либо приемлемым использование сущностей L2S во всем приложении?

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

Насколько сложно (по опыту) реорганизовать использование другой персистентной структуры позже?

Если вы используете L2S во всех своих слоях, то вам не следует задумываться о том, чтобы повторно их использовать, чтобы использовать другую среду персистентности. В этом и заключается преимущество использования фреймворка, такого как NHibernate или Entity Framework, на вашем уровне персистентности, поскольку, хотя он требует немного дополнительных усилий на начальном этапе, его будет легко поддерживать в долгосрочной перспективе

Answer 4

В основном, что мы сделали для проекта, так это то, что у нас был бизнес-уровень, который выполнял все «LINQing» для объектов L2S ... по сути, централизовал все запросы к одному слою через «объекты-менеджеры» (я думаю, это несколько сродни репозиториям).

Мы не использовали DTO для сопоставления с L2S; поскольку мы не чувствовали, это стоило усилий в этом проекте. Часть нашей логики заключалась в том, что, поскольку все больше и больше ORM поддерживают Iqueryable и схожий синтаксис с L2S (например, структурой сущностей), то, вероятно, было бы НЕ ТАК плохо переключаться на другой ORM, так что это не так уж плохо, IMO .

Answer 5

Похоже, вы должны рассмотреть шаблон ViewModel для WPF

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx