Core функционалност и ORM

1. Имам известни затруднения и пратих следното писмо до Митьо и Кънев:

   Имам проблем с проекта. В момента си пиша core функционалността и се замислям как после върху нея ще надградя със Sinatra и БД. В момента класовете ми имат доста полета, които принципно биха били полета на таблица. Четох малко за DataMapper и ActiveRecord и съвсем се обърках. Примерно имам един клас User с инстанционни променливи username, email, pass, realname да речем и това ми е в ядрото. Ако искам БД, то тоя клас не става ли ненужен, ако ползвам DataMapper(или ActiveRecord) например? Нещо не съм наясно. Не знам как да си обвия класовете, така че да ги ползвам с бази данни.

   Ето и отговора, който получих от Митьо:

   Във връзка с темата на въпроса ти, виж последния параграф в секцията "Архитектура" от документа с указания за проектите: https://gist.github.com/mitio/4135365#------ Там, освен указания, има и връзка към една блог публикация с примерен код.

   Моето обобщение е следното — да, до голяма степен класът, наследяващ/include-ващ ORM, било то DataMapper или ActiveRecord, ще се повтаря с класа от ядрото ти, особено ако основното нещо, което имаш във въпросния клас-ядро, са полета. В много случаи на практика хората не правят отделни класове за persistance и за моделиране на обектите от тяхната проблемна област. Понякога това е приемлив компромис, защото носи бързина на имплементация и простота на кода. Проблемът идва тогава, когато нещата започнат неизбежно да се усложняват като изисквания, когато по-голяма част от въпросната проблемна област се пренесе и моделира в код. Тогава кашата в тези "нераздробени" класове, грижещи се за persistance и за 1000 други неща, започва да става все по-трудна за управление, да не говорим за разделение. Просто когато човек разсъждава от предпоставката, че имаш таблица orders, която ти пази данните за поръчките и съответно клас Order, който е част от ORM-а и някак ти моделира тези данни, то извода, до който обикновено се стига е, че всичко за поръчки трябва да влиза в този клас. Това е порочен начин на мислене и е пътят към споменатата по-горе каша.

   Тук идва и моментът, в който се опитваме да ви сръчкаме да напипате границата между persistance и моделиране на обекти от проблемната област. Ако успеете да се "откачите" от оковите на ORM-а, ще ви бъде по-лесно да раздробите и моделирате правилно въпросната проблемна област. Ако се поддадете на изкушението да слеете ORM-кода с вашия domain-модел, то ще ви бъде много трудно да се измъкнете от това блато впоследствие.

   ПП: И една забележка, която получих: при проблеми, първо във форумите.

   Публикувано преди почти 12 години

2. Това не го разбрах много, много. Може ли някакъв пример? (cuteface)

   Публикувано преди почти 12 години

3. Аз все още медитирам над отговора. Примери ще са от полза, yup.

   А относно блог публикацията с примерния код, там се ползва този EDR (Entity Data Repository) gem. Такава имплементация ли е абстракцията, която ще ни откачи от "оковите" на ORM-a?

   Публикувано преди почти 12 години

4. Този пример с EDR е едно възможно решение. Като друг пример, бих могъл да ви посоча методът Backbone.sync, който е единствената абстракция за persistance в целия Backbone "фреймуърк". Ако някой иска да пази нещата в HTML5 local storage, например, вместо да прави AJAX заявки към някакъв JSON backend, това, което трябва да направи, е да предефинира една функция — Backbone.sync. Въпреки, че примерът е на JavaScript, смятам, че принципът е важен. Теглите една черта и казвате — всичко, което е свързано с persistance (зареждане, запазване), ще го делегирам ей натам. Ще му подавам ей такива обекти (хешове ли ще са, списъци ли, класчета ли) и той ще ми връща ей такива. Какво прави той вътрешно, какво се случва зад интерфейса, който тази абстракция предоставя, моята "основна" логика не я касае. Дали пази в паметта, дали пише във файлове, дали ръчка в SQL база — няма значение. И в тези обекти, грижещи се за persistance, очевидно няма място за бизнес логика. Има място само за едно и това са данни.

   Не искам да ви давам примерен код, защото ще ви подхлъзна мисленето в една-единствена посока. Това има много начини да се реализира и ми е интересно до какви изводи ще стигне всеки един от вас. Бъдете изследователи :)

   That being said, ако все още ви е твърде неясно и не може да си представите нищо, пишете, ще преосмисля позицията си за примера.

   Публикувано преди почти 12 години

5. Аз си представям нещо, но не съм сигурен, че представите ни ще съвпаднат на защитата..

   Публикувано преди почти 12 години

6. Тук сме за да експериментираме и да научим по нещо. Не се притеснявайте за такива неща като съвпадение на представи :)

   Публикувано преди почти 12 години

Трябва да сте влезли в системата, за да може да отговаряте на теми.