Используете объекты Linq-to-SQL в своем BLL или пользовательском интерфейсе?

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

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

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

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

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

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

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

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

Мысли?


repository-pattern wpf linq-to-sql dao data-access-layer
person Jack Ukleja    schedule 18.11.2009    source источник

Ответы (5)


arrow_upward
4
arrow_downward

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

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

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

Затем, когда / если вам понадобится другая структура персистентности, у вас вообще не будет проблем с BL или пользовательским интерфейсом, только на уровне данных - где вы этого хотите.

person Randolpho    schedule 18.11.2009
comment
с WPF пользовательскому интерфейсу действительно не нужно знать о конкретных объектах в какой-либо значительной степени благодаря мощной привязке данных - person Jack Ukleja; 18.11.2009
comment
хорошая идея для работы с интерфейсами, но в целом мне интересно, есть ли какие-нибудь болевые точки при построении вашей модели вокруг частичных классов L2S - person Jack Ukleja; 18.11.2009
comment
Ну, первая проблема, которую я заметил, заключается в том, что ваши операторы using должны быть внутри объявления пространства имен для файла частичного файла класса (обычно Foo.cs, если ваш файл L2S - Foo.dbml), иначе дизайнер сломается и сломается. . Но самая большая проблема - это ассоциации; вам придется создать несколько реализаций, которые приведут связанные сущности к их интерфейсу, а создание дерева / иерархии ассоциаций может быть грубым. Обычно лучше всего реализовать построение ассоциаций внутри уровня данных. - person Randolpho; 18.11.2009
comment
Кроме того, у вас все еще должна быть ссылка на конкретные классы, даже с потрясающей привязкой данных WPF. - person Randolpho; 18.11.2009

arrow_upward
1
arrow_downward

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

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

person Robert Harvey    schedule 18.11.2009
comment
Я думаю, что причина, по которой они не имеют большого значения в этом сценарии, заключается в том, что они напрямую используют объекты L2S в качестве своей модели предметной области. Я подозреваю, что многие не одобряют этого. Но он определенно быстро запускается и, вероятно, может отлично работать над этим проектом. - person Jack Ukleja; 18.11.2009
comment
Уместно это или нет, зависит от размера проекта. В небольших проектах (у меня есть одна с 30 таблицами в ней, а в StackOverflow их как минимум столько), объекты L2S будут работать нормально. - person Robert Harvey; 18.11.2009

arrow_upward
1
arrow_downward

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

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

person Giovanni Galbo    schedule 18.11.2009

arrow_upward
1
arrow_downward

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

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

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

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

person Illuminati    schedule 18.11.2009

arrow_upward
0
arrow_downward

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

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

person James Fleming    schedule 24.08.2010