Должны ли члены слоя БД быть статичными или экземплярами?

Question

Я видел проекты, в которых классы на уровне БД содержат только статические функции, и другие проекты, в которых эти классы необходимо создавать для доступа к функциям-членам.

Что "лучше" и почему?

Answer 1

Мне нравится, когда отдельный объект соотносится с одной записью в базе данных, то есть объект должен быть создан. Это ваш базовый шаблон ActiveRecord . По моему опыту, подход «один объект к одной строке» создает гораздо более плавное и грамотное представление в коде. Кроме того, мне нравится обрабатывать объекты как записи, а класс - как таблицу. Например, чтобы изменить имя записи, я делаю:

objPerson = new Person(id)

objPerson.name = "George"

objPerson.save()

пока все люди, которые живут в Луизиане, я бы мог

aryPeople = Person::getPeopleFromState("LA")

Существует множество критических замечаний в отношении Active Record. Особенно вы можете столкнуться с проблемами, когда вы запрашиваете базу данных для каждой записи, или ваши классы тесно связаны с вашей базой данных, создавая негибкость в обеих. В этом случае вы можете подняться на уровень вверх и пойти с чем-то вроде DataMapper .

Многие современные фреймворки и ORM знают о некоторых из этих недостатков и предоставляют решения для них. Проведите небольшое исследование, и вы начнете понимать, что эта проблема имеет ряд решений и все зависит от ваших потребностей.

Answer 2

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

Answer 3

Я бы сказал, что это зависит от того, что вы хотите, чтобы "слой БД" делал ...

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

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

Если, с другой стороны, вы хотите создать экземпляр класса, используя заданный параметр, такой как идентификатор (см. Ответ @ barret-conrad), для подключения к БД и получения необходимой записи, то вы, вероятно, захотите не хочу использовать статический метод в классе. Но даже тогда я бы сказал, что у вас, вероятно, есть какой-то класс DB Helper, в котором DID есть статические методы, на которые опирался ваш другой класс.

Answer 4

Как упоминалось в lomaxx, все дело в цели модели DB.

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

Answer 5

Зависит от того, на какую модель вы подписаны. ORM (объектно-реляционная модель) или интерфейсная модель. ORM сейчас очень популярен благодаря таким фреймворкам, как nhibernate, LINQ to SQL, Entity Framework и многим другим. ORM позволяет настраивать некоторые бизнес-ограничения вокруг вашей объектной модели и передавать их, фактически не зная, как они должны быть зафиксированы в базе данных. Все, что связано со вставкой, обновлением и удалением, происходит в объекте и на самом деле не должно сильно беспокоить разработчика.

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

Я бы сказал, иди с ORM.

Answer 6

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

Так что у вас может быть что-то вроде этого:

DbController acrhive = new DbController("dev");
DbController prod = new DbController("prod");

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

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