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

Question

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

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

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

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

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

Как я вижу это, если слой UI использует объекты L2S как простой в POCO (не касаясь любой L2S конкретных методов), то это должно быть очень легко реорганизовать позже, если это будет необходимо.

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

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

Мысли?

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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