Сообщение Re[9]: Фаулер. Архитектура от 26.07.2019 20:04
Изменено 26.07.2019 20:07 Буравчик
Re[9]: Фаулер. Архитектура
Здравствуйте, Cyberax, Вы писали:
C>Масло масляное какое-то. ORM и так является persistance-слоем.
Не. ORM является библиотекой для построения persistance-слоя.
Б>>- отвязывает приложение от схемы БД (схема БД меняется часто)
C>Этим должна заниматься ORM и само приложение.
Приложение и занимается. Этот код лежит в persistance слое.
Чтобы не пришлось при небольших изменениях схемы выискивать по всему приложению запросы, которые нужно поменять.
Б>>- устраняет дублирование запросов, созданных с помощью ORM
C>???
Я про повторение частей запросов, построенных с помощью ORM.
Т.е. нескольким запросам требуются одни и те же подзапросы.
Б>>- позволяет добавить SQL запросы в обход ORM
C>???
Это когда надо написать запрос на голом SQL. Где такой код хранить, как не в внутри persistance?
Б>>- позволяет добавить кеширование и делать другие оптимизации
C>Кэширование редко является полезным на уровне persistance.
Разные ситуации могут быть
C>В документе речь идёт об адаптерах — это таки технический термин. Означающий, что интерфейс ORM будет адаптироваться к внутреннему интерфейсу системы. От этого и возникает вопрос: нафига?
Этот адаптер — часть приложения, которая отвечает за persistance (т.е. persistance-слой). Реализует интерфейс persistance, а ORM — деталь реализации.
В некотором роде ORM адаптируется под интерфейс persistance. Хотя, аддаптер может и не совсем подходящий термин.
С другой стороны, и persistance тоже не совсем слой (в "старом" понимании). Есть же и другие "слои" в инфраструктуре — слой поиска, слой нотификации, слой интеграции с какой-нибудь внешней системой и т.п.
C>Масло масляное какое-то. ORM и так является persistance-слоем.
Не. ORM является библиотекой для построения persistance-слоя.
Б>>- отвязывает приложение от схемы БД (схема БД меняется часто)
C>Этим должна заниматься ORM и само приложение.
Приложение и занимается. Этот код лежит в persistance слое.
Чтобы не пришлось при небольших изменениях схемы выискивать по всему приложению запросы, которые нужно поменять.
Б>>- устраняет дублирование запросов, созданных с помощью ORM
C>???
Я про повторение частей запросов, построенных с помощью ORM.
Т.е. нескольким запросам требуются одни и те же подзапросы.
Б>>- позволяет добавить SQL запросы в обход ORM
C>???
Это когда надо написать запрос на голом SQL. Где такой код хранить, как не в внутри persistance?
Б>>- позволяет добавить кеширование и делать другие оптимизации
C>Кэширование редко является полезным на уровне persistance.
Разные ситуации могут быть
C>В документе речь идёт об адаптерах — это таки технический термин. Означающий, что интерфейс ORM будет адаптироваться к внутреннему интерфейсу системы. От этого и возникает вопрос: нафига?
Этот адаптер — часть приложения, которая отвечает за persistance (т.е. persistance-слой). Реализует интерфейс persistance, а ORM — деталь реализации.
В некотором роде ORM адаптируется под интерфейс persistance. Хотя, аддаптер может и не совсем подходящий термин.
С другой стороны, и persistance тоже не совсем слой (в "старом" понимании). Есть же и другие "слои" в инфраструктуре — слой поиска, слой нотификации, слой интеграции с какой-нибудь внешней системой и т.п.
Re[9]: Фаулер. Архитектура
Здравствуйте, Cyberax, Вы писали:
C>Масло масляное какое-то. ORM и так является persistance-слоем.
Не. ORM является библиотекой для построения persistance-слоя.
Б>>- отвязывает приложение от схемы БД (схема БД меняется часто)
C>Этим должна заниматься ORM и само приложение.
Приложение и занимается. Этот код лежит в persistance слое.
Чтобы не пришлось при небольших изменениях схемы выискивать по всему приложению запросы, которые нужно поменять.
Б>>- устраняет дублирование запросов, созданных с помощью ORM
C>???
Я про повторение частей запросов, построенных с помощью ORM.
Т.е. нескольким запросам требуются одни и те же подзапросы.
Б>>- позволяет добавить SQL запросы в обход ORM
C>???
Это когда надо написать запрос на голом SQL. Где такой код хранить, как не в внутри persistance?
Б>>- позволяет добавить кеширование и делать другие оптимизации
C>Кэширование редко является полезным на уровне persistance.
Разные ситуации могут быть
C>В документе речь идёт об адаптерах — это таки технический термин. Означающий, что интерфейс ORM будет адаптироваться к внутреннему интерфейсу системы. От этого и возникает вопрос: нафига?
Этот адаптер — часть приложения, которая отвечает за persistance (т.е. persistance-слой). Реализует интерфейс persistance, а ORM — деталь реализации.
В некотором роде ORM адаптируется под интерфейс persistance, под требования приложения. Хотя, аддаптер может и не совсем подходящий термин.
С другой стороны, и persistance тоже не совсем слой (в "старом" понимании). Есть же и другие "слои" в инфраструктуре — слой поиска, слой нотификации, слой интеграции с какой-нибудь внешней системой и т.п.
C>Масло масляное какое-то. ORM и так является persistance-слоем.
Не. ORM является библиотекой для построения persistance-слоя.
Б>>- отвязывает приложение от схемы БД (схема БД меняется часто)
C>Этим должна заниматься ORM и само приложение.
Приложение и занимается. Этот код лежит в persistance слое.
Чтобы не пришлось при небольших изменениях схемы выискивать по всему приложению запросы, которые нужно поменять.
Б>>- устраняет дублирование запросов, созданных с помощью ORM
C>???
Я про повторение частей запросов, построенных с помощью ORM.
Т.е. нескольким запросам требуются одни и те же подзапросы.
Б>>- позволяет добавить SQL запросы в обход ORM
C>???
Это когда надо написать запрос на голом SQL. Где такой код хранить, как не в внутри persistance?
Б>>- позволяет добавить кеширование и делать другие оптимизации
C>Кэширование редко является полезным на уровне persistance.
Разные ситуации могут быть
C>В документе речь идёт об адаптерах — это таки технический термин. Означающий, что интерфейс ORM будет адаптироваться к внутреннему интерфейсу системы. От этого и возникает вопрос: нафига?
Этот адаптер — часть приложения, которая отвечает за persistance (т.е. persistance-слой). Реализует интерфейс persistance, а ORM — деталь реализации.
В некотором роде ORM адаптируется под интерфейс persistance, под требования приложения. Хотя, аддаптер может и не совсем подходящий термин.
С другой стороны, и persistance тоже не совсем слой (в "старом" понимании). Есть же и другие "слои" в инфраструктуре — слой поиска, слой нотификации, слой интеграции с какой-нибудь внешней системой и т.п.