Comments 20
Спасибо. Действительно на практике достаточно сложно связать мир SQL с миром ООП. Или упираешься в возможности ORM или начинает вылезать сырой SQL в коде, и приходится писать свой механизм мапинга, который за частую бывает очень сложным и кривым.
Если не трудно, оформите резюме на тему «модели и технологии доступа к данным».
Если не трудно, оформите резюме на тему «модели и технологии доступа к данным».
f
Мы должны смириться с мыслью о том, что ORM являются плохими, уродливыми и перегруженными.©
Альтернатива?
учить SQL. Это никогда не помешает.
Проблема не в изучении SQL и даже не в производительности. Я имею ввиду проблему архитектурного плана. Как максимально закрыть уже написанный код для изменений, иметь возможность добавлять новый функционал и расширять схему данных. Как избежать описания схемы дважды и более раз (в SQL виде и в определении классов). И при всем этом не потерять в функциональности реляционного подхода. Если тупо втравлять SQL код в код ООП то получится спагетти. А точнее даже говнокод. ORM подход пытается решать эти проблемы.
SQL появился до ООП и прекрасно работал и работает вообще без него. Для каждой заачи свой инструмент, о чём, кстати, в этом переведённом тексте и говорится.
Скажите Вы сайты, GUI, демоны, серверлеты тоже на чистом SQL собираетесь писать? Да можно в принципе это сделать. К слову такую вещь я проделывал с PostgreSQL, с использованием хранимых процедур написанных на PL/Python и PL/pgSQL. Но получалось не красиво. Возникала привязка к конкретной СУБД и еще куча проблем. SQL мир таблиц и запросов, ООП и функциональное программирование мир объектов и функций. И напрямую их связать нельзя. Плохо получается. А взаимодействовать они должны. Нужен «мост» который бы их мог связать. Вот об этом «мосте» я и веду речь.
UFO just landed and posted this here
Поясните в каком месте она «альтернатива» — как указанные вами подходы спасают от процедуры «маппировка нечто (из субд) на объекты».
UFO just landed and posted this here
«Кошка это альтернатива асфальту».
Общественность вам будет благодарна за топик «CQRS + DDD + ES круче чем любая ORM», он же появится — одним комментарием не охватить…
Вы как студент на экзамене в ответах на вопрос, на который он не знает ответа. «Расскажу всё — авось прокатит».
Знать модные слова не означает что из понимают.
Общественность вам будет благодарна за топик «CQRS + DDD + ES круче чем любая ORM», он же появится — одним комментарием не охватить…
Вы как студент на экзамене в ответах на вопрос, на который он не знает ответа. «Расскажу всё — авось прокатит».
Знать модные слова не означает что из понимают.
Благодаря вашему комментарию, увидел Mighty Moose, про который кстати писали на хабре.
Использовать СУБД, поддерживающую одновременно NoSQL+SQL+ООП интерфейсы, как внутри (для хранимых процедур) так и снаружи (С#, Java, Delphi, node.js, ...).
BTW, как генерить такие (как на картинке к статье) деревья программно? Где почитать, а еще лучше, если не жалко, то можно код на любом вменяемом языке.
rosettacode.org/wiki/Fractal_tree например, но с вашим вопросом лучше в гугл (фракталы) или в QA.
для Event Sourcing есть реализация на .Net github.com/joliver/EventStore
А кто может подсказать, какие варианты решения проблемы могут быть, если возникает необходимость реализации слоя доступа к данным, источник которых разнороден. В моём случае мне нужно реализовать слой, который мог бы работать как с файлом формата xml, так и базой данных, представляющей те же данные, но уже в реляционном виде?
Sign up to leave a comment.
Выбор ORM-стратегии (.NET)