Это кажется своего рода болью, чтобы иметь мои классы Американского лося. Затем использовать DBIx:: Класс для получения набора результатов.. затем вручную отобразить мой набор результатов на классы американского лося.
Если вам приходится создавать карты туда и обратно между классами Moose и схемой DBIC, возможно, вам стоит обратить внимание на постоянное хранилище объектов, например KiokuDB.
Вы теряете некоторые возможности реляционной базы данных, особенно если у вас есть существующая схема, но приобретаете множество возможностей, главной из которых является спокойное отображение между хранилищем данных и вашей объектной моделью. DBI back-end для KiokuDB, вероятно, является лучшим примером такого компромисса. База данных сильно де-нормализована, но это потому, что она работает как эффективное хранилище ключей.
Однако KiokuDB может работать с механизмами хранения, оптимизированными для такого рода данных. Она поддерживает несколько современных "NoSQL" знаменитостей, включая CouchDB и MongoDB. Она также поддерживает старую любимицу фанатов BerkelyDB.
Kioku не является решением для каждой проблемы, но он довольно успешно используется в Parking Mobility для бесперебойной обработки всех данных.
Вы можете использовать Moose с DBIC без проблем. На самом деле мне нравится использовать MooseX::Declare, так как я нахожу расширенный синтаксис очень полезным при разработке надежных публичных apis, например:
use MooseX::Declare;
class MyApp::Schema::Result::Geo::Division
extends MyApp::Schema::Result {
use Locale::Geocode::Division;
__PACKAGE__->table('division');
__PACKAGE__->add_columns(
fk_territory_id => {
data_type => 'char',
size => '36',
},
division_id => {
data_type => 'char',
size => '36',
},
code => {
data_type => 'varchar',
size => '5',
},
created => {
data_type => 'datetime',
set_on_create => 1,
},
);
__PACKAGE__->set_primary_key('fk_territory_id','division_id');
__PACKAGE__->uuid_columns('division_id');
__PACKAGE__->add_unique_constraint(['fk_territory_id','code']);
__PACKAGE__->belongs_to(
territory => 'MyApp::Schema::Result::Geo::Territory',
{'foreign.territory_id' => 'self.fk_territory_id'},
);
method as_geocode_division {
Locale::Geocode::Division->new($self->code);
}
__PACKAGE__->meta->make_immutable(inline_constructor => 0);
} 1;
Похоже, вы описываете именно то, что я недавно написал, чтобы отобразить значения атрибутов Moose на значения Rose::DB::Object (при этом объект db и objectmanager содержатся в приватных атрибутах) и наоборот. Изначально я использовал триггеры вокруг каждого атрибута Moose для немедленной записи в объект Rose, но позже отказался от этого подхода и лениво записывал значения только по мере необходимости (т.е. во время операции ->save()
). Я реализовал это с помощью нескольких ролей и класса sugar, который автоматически устанавливал для соответствующих атрибутов признак, указывающий "Я - поле таблицы".
Но не делайте так, как я - просто используйте DBIx::Class напрямую! Следующая основная версия в любом случае будет переписана на Moose, так что я слышал.