Плюсы и минусы использования Singleton Pattern в DAL

Question

Я попросил использовать DAL с одноэлементным шаблоном, но я думаю, что сложно объединить соединения, использовать транзакции и т. Д.

Мне бы хотелось узнать плюсы и минусы, а также узнать, как лучше всего объединить соединения, поскольку на разрабатываемом мной сайте может быть более 500 одновременно работающих пользователей.

Сервер БД - Oracle 10g.

DAL использует корпоративную библиотеку 3.1

Answer 1

Шаблон синглтона отлично подходит для DAL - я использую его в своем собственном корпоративном веб-приложении (сотни пользователей и более 2000 методов в 20 с небольшим классах). Пул соединений действительно лучше всего обрабатывается ado.net и самим сервером sql. Если вы хотите иметь несколько типов внутреннего сервера, это не проблема. Даже с одноэлементным шаблоном вам, вероятно, понадобится централизованный класс доступа к данным, который обрабатывает особенности фактического прямого вызова базы данных (с передачей параметров, имен текста / процедур, учетных данных / строки подключения).

В моей ситуации каждому методу по одному соответствует 1: 1 с хранимой процедурой в моей базе данных. По сути, это делает C # «передний конец» хук для каждой хранимой процедуры, так что они могут быть вызваны почти как собственный код C #, говоря синтаксически. Это делает звонки в DAL очень просто. У меня есть несколько синглетонов из-за огромного количества SP, о которых идет речь. У каждого SP есть префикс, такой как Development_, или Financial_, или Organization_ или что-то еще. Затем у меня есть одноэлементный класс, который соответствует каждому, например, «Развитие», «Финансы» или «Организация». Таким образом, sp Organization_ViewData в C # будет методом с именем ViewData для одноэлементного класса с именем Organization.

Конечно, это всего лишь один из способов сделать это, но я обнаружил, что он очень хорошо работал с несколькими разработчиками и большим количеством кода за последние шесть лет. Главное, чтобы последовательность была ключевой. Если интерфейсный программист смотрит на имя метода у одного из ваших синглтон-брокеров, он должен точно сказать им, куда он направляется в конец базы данных. Таким образом, если есть проблема, или если кому-то приходится искать в коде, чтобы попытаться его понять, нужно меньше отслеживать.

Answer 2

Лучшая практика для пула подключений - не реализовывать это самостоятельно, а позволить инфраструктуре ADO.NET позаботиться об этом.

Вы можете установить параметры пула соединений в качестве параметров в строке соединения. Затем каждое соединение, открытое с этой строкой, будет предоставлено из пула соединений, который реализован и управляется платформой. Когда вы закрываете или удаляете OracleConnection, базовое соединение не разрушается, а вместо этого возвращается в пул.

Это описано здесь: http://msdn.microsoft.com/en-us/library/ms254502.aspx

Об использовании Singletons в целом: я использовал их, чтобы обернуть слой доступа к данным, и он всегда работал хорошо.

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

Answer 3

Мне немного неловко использовать синглтоны в случае DAL. Что делать, если я хочу использовать более одной базы данных. Возможно, я хочу использовать MsSQL для счетов, но Active Directory для аутентификации. Или, может быть, я хочу использовать MySQL для сообщений на форуме, а PostgreSQL - для геокластеризации (более реалистично для меня, хе). Одноэлементные интерфейсы могут усложнить тестирование слоев базы данных, когда я не могу передать фиктивное соединение с базой данных в тест.

Answer 4

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

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

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

Примечание. Говоря о пулах соединений, единственная важная вещь, о которой вы должны позаботиться, - это следовать схеме «открывать поздно, закрывать рано». Это означает, что следует как можно больше отложить открытие соединения и закрыть его как можно скорее после того, как вы сделали с ним все, что вам нужно.

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

Answer 5

Использование singleton для фабрики соединений с базой данных в DAL довольно распространено. Это позволяет вам легче подключать различные реализации фабрики, не изменяя много кода. Многим людям не нравится шаблон синглтона, но я думаю, что он хорошо работает для такого типа вещей.

Answer 6

Я не знаю о DAL, но шаблон синглтона - отличный способ сделать данные глобальными, сохраняя при этом хорошую инкапсуляцию.