Programming
.NET
Comments 20
0
Спасибо. Действительно на практике достаточно сложно связать мир SQL с миром ООП. Или упираешься в возможности ORM или начинает вылезать сырой SQL в коде, и приходится писать свой механизм мапинга, который за частую бывает очень сложным и кривым.
Если не трудно, оформите резюме на тему «модели и технологии доступа к данным».
0
Мы должны смириться с мыслью о том, что ORM являются плохими, уродливыми и перегруженными.©
+1
Проблема не в изучении SQL и даже не в производительности. Я имею ввиду проблему архитектурного плана. Как максимально закрыть уже написанный код для изменений, иметь возможность добавлять новый функционал и расширять схему данных. Как избежать описания схемы дважды и более раз (в SQL виде и в определении классов). И при всем этом не потерять в функциональности реляционного подхода. Если тупо втравлять SQL код в код ООП то получится спагетти. А точнее даже говнокод. ORM подход пытается решать эти проблемы.
0
SQL появился до ООП и прекрасно работал и работает вообще без него. Для каждой заачи свой инструмент, о чём, кстати, в этом переведённом тексте и говорится.
0
Скажите Вы сайты, GUI, демоны, серверлеты тоже на чистом SQL собираетесь писать? Да можно в принципе это сделать. К слову такую вещь я проделывал с PostgreSQL, с использованием хранимых процедур написанных на PL/Python и PL/pgSQL. Но получалось не красиво. Возникала привязка к конкретной СУБД и еще куча проблем. SQL мир таблиц и запросов, ООП и функциональное программирование мир объектов и функций. И напрямую их связать нельзя. Плохо получается. А взаимодействовать они должны. Нужен «мост» который бы их мог связать. Вот об этом «мосте» я и веду речь.
0
не нужен никакой мост. Каждый должен заниматься своим.

Ни разу не видел потребности в лишнем коде (орп) у команд имеющих в своём составе хороших базаданщиков.
+4
Поясните в каком месте она «альтернатива» — как указанные вами подходы спасают от процедуры «маппировка нечто (из субд) на объекты».
0
Ну если кратко — то хранение текущего состояния объекта в виде событий, которые происходили с ним в прошлом, позволяет значительно упростить структуры данных необходимые для хранения состояния объекта. По большому счету, мы просто храним линейный список событий того, что происходило в системе. Каждое событие представляет из себя самодостаточный набор данных о том, что произошло с нашим объектом. Вычитав из БД и проиграв эти события на «пустом» объекте мы получаем его текущее состояние. Нам и база данных то особенно и не нужна — важен только лог событий.

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

Тема на самом деле довольно обширна — одним комментарием ее не охватишь — как минимум тут уже проскакивала статья ну и в Сети есть еще что почитать на эту тему.
0
«Кошка это альтернатива асфальту».
Общественность вам будет благодарна за топик «CQRS + DDD + ES круче чем любая ORM», он же появится — одним комментарием не охватить…
Вы как студент на экзамене в ответах на вопрос, на который он не знает ответа. «Расскажу всё — авось прокатит».

Знать модные слова не означает что из понимают.
0
Ну «круче» это Вы сами откуда-то взяли. Речь шла просто об альтернативе, при использовании которой, роль ORM в проекте не так важна.

Своим комментарием, я хотел сказать что «маппировка» упрощается при таком подходе(нет потребности в сложном маппинге).

зы. Извините, участвовать в срачах (мне показалось Вам это интересно) у меня времени нет. Дискуссию считаю закрытой. See you!
0
Использовать СУБД, поддерживающую одновременно NoSQL+SQL+ООП интерфейсы, как внутри (для хранимых процедур) так и снаружи (С#, Java, Delphi, node.js, ...).
0
BTW, как генерить такие (как на картинке к статье) деревья программно? Где почитать, а еще лучше, если не жалко, то можно код на любом вменяемом языке.
0
А кто может подсказать, какие варианты решения проблемы могут быть, если возникает необходимость реализации слоя доступа к данным, источник которых разнороден. В моём случае мне нужно реализовать слой, который мог бы работать как с файлом формата xml, так и базой данных, представляющей те же данные, но уже в реляционном виде?
Only those users with full accounts are able to leave comments. , please.