Плюсы и минусы использования одноэлементного шаблона в DAL

Question

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

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

Сервером базы данных является Oracle 10g.

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

Answer 1

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

В моей ситуации каждый метод в отдельности соответствует 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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

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

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