Архитектура приложения Winforms с использованием LinqToSql - PullRequest
3 голосов
/ 30 июля 2009

Я запускаю новое приложение Winforms, и я всегда использовал традиционные методы ADO.NET в моем DAL (... да, жесткое кодирование!)

Ранее я использовал Linq во многих случаях, но больше для adhoc запросов, поэтому у меня есть некоторый опыт работы с ним, и мне понравилось, как легко было писать код запросов. Возможно, я хотел бы заменить существующий DAL на чистые запросы LINQ. Я знаю, что это может вызывать озабоченность, поэтому мне нужна ваша помощь.

Если бы мне пришлось делать такие вещи, как я всегда делал в прошлом, я бы структурировал свое приложение так:

  • [AppName] .ClientUI -> настольный клиент Presentaion layer
  • [AppName] .WebUI -> слой веб-презентации
  • [AppName] .DAL -> ADO.NET Уровень доступа к данным
  • [AppName] .BLL -> Уровень бизнес-логики (проверка, дополнительные вычисления, + классы менеджера)
  • [AppName] .BE -> Бизнес-объекты, содержащие бизнес-объекты и классы коллекций

Если честно, я всегда использовал это в веб-приложениях и никогда раньше не создавал n-слойное приложение Winforms.

Если я захочу заменить мои старые методы DAL на методы LINQ, какие проблемы я готовлю?

Наконец, даже рекомендуется ли использовать LINQ в многослойном приложении? Иногда я думаю, что использовать старые методы ADO.NET все еще лучше ... больше работать, но лучше. Я имею в виду - и исправьте меня, если я ошибаюсь - в основе всех этих новых технологий (которые призваны сделать нашу работу разработчиков лучше) не все ли они до сих пор используют традиционный ADO.NET???

Надеюсь, кто-то может пролить свет на это! :)

Ответы [ 2 ]

2 голосов
/ 30 июля 2009

Для прямого клиентского приложения winforms, которое подключается напрямую к базе данных, Linq является хорошей заменой ADO.NET, есть очень мало ошибок, с которыми вы столкнетесь. Используйте инструмент типа SQLMetal (или конструктор, встроенный в VS2008), чтобы сгенерировать объекты данных Linq и классы соединений с базой данных. Если вы хотите использовать сгенерированные объекты в качестве объектов «BE», вы можете просто скопировать этот материал и переместить его в любую нужную вам сборку (если вы хотите разделить сборки). Или же вы можете просто предоставить отдельные «бизнес-объекты» и слой перевода, который копирует данные из BE в сгенерированные объекты Linq и обратно.

Единственное, что я несколько раз сталкивался с Linq, это то, что он не очень хорошо поддерживает отключенные архитектуры. Например, если вы хотите иметь свой DAL на сервере и подключить к нему все свои клиентские приложения, вы столкнетесь с проблемами, если просто разрешите передавать свои объекты linq через сервер.

Если вы решите иметь отдельные бизнес-объекты (или иметь отключенную архитектуру), вы обнаружите, что вам нужно тщательно управлять отключением объектов Linq от контекста данных, а затем повторно присоединять их, когда вы будете готовы сохранить / обновить. Сначала стоит сделать несколько прототипов в этой области, чтобы убедиться, что вы понимаете, как это работает.

Другая вещь, которая часто вводит людей в заблуждение, заключается в том, что запросы linq не выполняются немедленно к базе данных, они выполняются только по мере необходимости в данных. Остерегайтесь этого, так как он может поймать вас, если вы этого не ожидаете (и это трудно обнаружить при отладке, потому что когда вы смотрите на запрос linq в отладчике, он будет выполняться для получения данных).

Также стоит рассмотреть платформу Entity как альтернативу linq2sql (вы все еще можете выполнять запросы linq2EF). EF является более полной ORM и имеет лучшую поддержку для отображения связанных таблиц на несколько объектов, но все еще страдает от слабой поддержки отключенных приложений. EF в .net 4.0 должен иметь лучшую поддержку для отключенных архитектур.

2 голосов
/ 30 июля 2009

Я сделал это в обе стороны.

Вы правы, откат ADO.NET DAL вручную - это больше работы, так что вы получаете выигрыш в производительности для этой дополнительной работы? Да, когда вы используете классы Linq to SQL, вы получаете от 7% до 10% от верха в качестве накладных расходов. Однако за эти небольшие накладные расходы вы получаете множество преимуществ:

  • Ленивая загрузка (которая обеспечивает повышение производительности за счет отсрочки выполнения запросов до тех пор, пока они на самом деле не нужны)
  • CRUD бесплатно, со встроенным обработка параллелизма
  • Linq, IQueryable и все добро, которое обеспечивает
  • Частичные классы позволяют вставлять бизнес логика и валидация int ваши классы Linq to Sql, без беспокоиться о коде Linq to SQL генератор перезаписывает их.

Конечно, если вам ничего не нужно, Linq to SQL может показаться роскошью. Тем не менее, я считаю, что Linq to SQL проще в обслуживании, тем более что классы DAL могут быть восстановлены при изменении базы данных.

И да, Linq to SQL использует ADO.NET под капотом.

Многоуровневая история Linq to SQL менее ясна, в значительной степени из-за способа обработки объекта DataContext. Я предлагаю проверить этот проект CodePlex:

Пример многоуровневой архитектуры для Linq to Sql
http://www.codeplex.com/MultiTierLinqToSql

...