Perl DAL Design Вопросы

Question

Недавно я работал над некоторыми проектами на Perl, и я очень начинающий программист на Perl. Я экспериментировал с DBIx :: Class и до сих пор очень рад гибкости и простоте использования. Мне любопытно, хотя. Я родом из .NET, и кажется, что мы тратим много времени на абстрагирование нашего DAL в определенной степени. Это хорошая идея с таким языком, как Perl?

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

Answer 1

Re: Отношения ORM в приложении ...

Надеюсь, это тот ответ, который вы ищете ...

В большинстве фреймворков веб-приложений в мире сценариев (например, perl, ruby, python, php) большую часть времени я видел бизнес-логику, реализованную на уровне объектов ORM. Например. в приложении Rails он находится на уровне ActiveRecord; если вы используете DBix::Class, это будет на уровне Result -класса.

Более конкретно, в случае DBIx::Class, если у вас есть таблица с именем VENDOR, будет класс с именем MySchema::Result::Vendor, который представляет одну строку в таблице VENDOR. Просто добавьте свои бизнес-методы в этот класс.

Одним из недостатков этого подхода является то, что он связывает вашу бизнес-логику с классом ORM, что может усложнить (модульное) тестирование. Одним из решений этой проблемы является использование облегченной базы данных для модульных тестов (например, SQLite), а ORM, такой как DBIx::Class, облегчит переключение между ними. Конечно, это не будет работать, если вы полагаетесь на функции SQL, которые не реализованы в SQLite.

Другой подход - поместить ваши методы бизнес-логики в роль Moose. Затем эти методы можно объединить либо в класс DBIx :: Class Result, либо в фиктивный объект для тестирования. Я могу привести пример, если хотите.

Одно большое предположение из вышесказанного состоит в том, что ваш бизнес-объект = одна строка в базе данных. Если это не так (т. Е. Ваш бизнес-объект охватывает несколько таблиц), вы, вероятно, захотите создать «оболочку» или контейнерный объект, имеющий в качестве экземпляров элементы каждый из составляющих объектов ORM. К счастью, в Moose есть отличное средство для делегирования методов (поиск Moose delegation и атрибут handles объявлений членов экземпляра), поэтому относительно легко сделать составной бизнес-объект из двух или более объектов ORM. Опять же, я могу привести вам пример этого, если хотите.

НТН

Answer 2

Я давно работал в проектах на Perl для Интернета. Но после работы с такими вещами, как Django, инструменты Perl, такие как DBI и т. Д., Теперь кажутся мне довольно элементарными и устаревшими. Взгляните на django ORM, например, он элегантен и очень продуктивен в использовании, вы можете обойти его, если ваш запрос слишком сложен или ORM мешает ...

В эти дни я бы выбрал python или ruby ​​для подобных проектов. Для одного лайнера, небольшого разбора текста или сисадмина я все еще люблю использовать небольшие фрагменты perl. Но сейчас я больше увлекаюсь DRY, чем TMTOWTDI, чтобы написать несколько строк кода.