Как обрабатывать соединения на уровне доступа к данным (.net) - PullRequest
2 голосов
/ 28 января 2009

Я пишу слой доступа к данным. Я запутался в управлении соединениями в системе. Я знаю, что .net использует пул соединений. Но я не хочу открывать и закрывать соединения с базой данных во всех операциях dml или во всех запросах sql. Как я могу справиться с этим? Где и когда (возможно, в глобальном asax, который использует уровень доступа к данным или на уровне доступа к данным), соединения должны управляться?

Ответы [ 7 ]

11 голосов
/ 28 января 2009

Вы должны открывать и закрывать соединения sql для каждого запроса, если только вы не запускаете пакет операторов.

«Открывайте поздно, закрывайте раньше» - так вы всегда должны обрабатывать соединения с базой данных.

Если вы делаете это традиционным способом (делая свои собственные запросы), MS уже написала хороший интерфейс доступа к данным. * * * * * * * * * * * * * * * * * * * * * * * * *

* * * * * * * * * * * * * * *.

Если вы не хотите беспокоиться о написании запросов, я предлагаю вам взглянуть на linq2Sql или linq2EF (предпочтительно). Они значительно упростят ваше кодирование.

6 голосов
/ 28 января 2009

Почему вы не хотите открывать / закрывать соединение для каждой дискретной логической операции? Большинство существующих DAL ведут себя именно так. Обычно не стоит пытаться перехитрить то, что среда выполнения сделает для вас автоматически, например, разумно управлять вашими соединениями. Прежде чем тратить время и усилия, чтобы добавить эту сложность в свое приложение, у вас должны быть очевидные технические потребности.

2 голосов
/ 29 января 2009

А как насчет операций, которые должны выполняться как транзакция?

Это ваш BL, который выполняет операции и логика / проверки правильности?

Допустим, у вас есть слой BL, который

  1. обновляет информацию о вашей учетной записи клиента. (DAL -> обновить запись о клиенте)
  2. вставить адресную запись. (DAL -> вставить адрес)
  3. проверяет вашего клиента по третьему объекту. (DAL -> получить клиент & адрес & объект проверки)

Итог: клиент недействителен. Поэтому вам нужно откатить транзакцию.

Как можно решить эту проблему?

0 голосов
/ 16 сентября 2009

Мне не очень понятен этикет для ответов на старые вопросы, и я не мог понять, как комментировать другой ответ (я новичок в SO, и я не совсем выпил свою первую чашку кофе сегодня, так что сделай мне немного расслабиться =]).

Я всегда пишу свои DAL для открытия / закрытия соединений с каждым запросом и позволяю пулу соединений драйвера выполнять работу по управлению соединениями.

Тем не менее, у меня есть многопользовательское настольное приложение, которое использует общую базу данных MS Access (SQL Express практически не использовался, когда создавалось это приложение), и я иногда видел ошибки, указывающие на повреждение. В этой статье MS рекомендуется использовать только одно соединение для всего приложения:

"Повторное открытие и закрытие базы данных Microsoft Access не рекомендуется. Откройте базу данных один раз в начале приложения, а затем закройте базу данных в конце приложения."

Мое приложение является многопоточным, поэтому я полагаю, что мне придется пересмотреть рекомендацию "открыть одно соединение в THREAD", чтобы избежать коллизий. У кого-нибудь есть опыт использования баз данных общего доступа с OLEDB и подобных проблем с повреждением?

0 голосов
/ 28 января 2009

Мой совет после написания нескольких слоев данных в .Net (и еще несколько в VB6 ранее):

  1. используйте наборы данных, а не читателей, если это вообще возможно.
  2. создайте и разорвите соединения (у вас нет в любом случае> 1 открытого считывателя на любом одном соединении).
  3. сделать работу с параматеризованными СП на заднем конце. 3.5 убедитесь, что все таблицы имеют уникальный первичный ключ с одним полем!

слегка ОТ? ...

  1. используйте генерацию кода (вашего или купленного в) для создания классов ORM - но имейте в виду, что они не являются первичными и заканчивают все (одна таблица за раз удобна - но может заставить вас писать уродливый неэффективный код где один запрос на серверной части с объединениями или хитрым SP или представлением сделает работу НАМНОГО лучше).
  2. читать о методе Transaction объекта Connection - очень очень удобно (хотя некоторые вещи в db, для которых требуется транзакция (например, удаление, где есть отношения), должны быть в транзакции на стороне сервера.

Мой последний базовый DAL (без ORM) занял у меня полчаса, и он компактен и хорош эффективный. Корпоративный материал MS ОГРОМНЫЙ *

И последнее: лично мне кажется, что строго типизированные наборы данных, сгенерированные из xsds, имеют большое раздражение (и раздувание) для коэффициента усиления - и то, как они заставляют вас обрабатывать NULL sux в течение длительного времени. Весь код, который вы пишете для их использования, тоже ненормальный ... или вы в конечном итоге понижаете их до DataSet, чтобы фактически получить библиотеку эффективного, неповторяющегося кода.

0 голосов
/ 28 января 2009

Вы действительно должны открывать / закрывать для каждой операции. Не рассматривайте использование Соединения как дорогостоящую операцию, потому что это просто не так. Когда вы открываете соединения на своем сайте, они будут создаваться в пуле соединений. Когда вы «закрываете» соединение, пул соединений не освобождает соединение: оно держит его под рукой, готовое к повторному использованию. Таким образом, хотя самый первый вызов, приводящий к новому соединению, занимает немного больше времени, последующие соединения очень быстрые.

Обновление: это особенно верно в веб-приложении! не пытайтесь один раз открыть соединение в глобальном объекте и повторно использовать его во всех потоках, иначе ваш сайт просто не будет работать.

0 голосов
/ 28 января 2009

Управление соединением не должно осуществляться DAL.

Единственный уровень, который может быть ответственным / может решить, следует ли открыть новое соединение или соединение должно быть закрыто, это уровень обслуживания или прикладной уровень, который использует DAL. Этот уровень является единственным уровнем, который осведомлен о контексте, и поэтому на этом уровне вы можете решить, следует ли закрыть соединение или оставить его открытым, поскольку существуют другие соединения с БД, которые должны использовать то же соединение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...