LINUX.ORG.RU

История изменений

Исправление dimgel, (текущая версия) :

Дело не в профите. Гугли:

  1. «anemic vs rich domain model» – попадёшь на статью Фаулера; её не читай! Он известный адепт rich, в чём сам открытым текстом признавался. А читай стародавние срачи на RSDN, особо обращая внимание на посты IT, Sinclair и другие с ненулевыми оценками. Причём там была традиционная забава: в каждом из этих срачей обязательно выносили Фаулера вперёд ногами. :)

  2. «heavy vs lightweight ORMs» – в принципе, идёт паровозом к предыдущему: в теории эти вещи ортогональны, но на практике они строго коррелируют: heavy ORM используют c rich domain model, lightweight ORM – с anemic. Тяжёлые ORM – это как раз JPA; лёгкие – LINQ.

  3. Ну и может про «JPA vs LINQ» чего полезного нагуглится. По крайней мере, насколько я могу судить, именно LINQ выпустил лёгкие ORM в массы; и жаверы с тех самых пор и страдают, что у них такого нет. Для scala есть несколько решений; из них SLICK от авторов самой скалы – говно.

// Корректности ради: LINQ – более универсальная вещь, применимая не только к базам.

Фух. думал, стошнит пока допишу: дюже много вдруг вспомнилось и из тех срачей, и из собственных экспериментов на тему «когда heavy ORM всё-таки полезны». Обсуждать подробности и тем более спорить желания не имею.

UPD: Впрочем, одну вещь таки-напишу: причина, по которой heavy ORM (hibernate, и основанный на нём стандарт JPA) столь сложны, что у многих вызывают законную ненависть, очень проста и С ГОРДОСТЬЮ описана в библии по хиберу: это «paradigm mismatch bridge». Т.е. мост между разными парадигмами представления данных: реляционной и сетью объектов. Для меня это вообще матерное словосочетание, потому как это целый класс идеальных в своей переусложнённости примеров «дырявой абстракции». К этому же классу, например, принадлежат ещё stateful web frameworks.

Отсюда я вывел простое правило: нужно работать как можно ближе к базовым используемым технологиям (relative database, stateless web), и не увлекаться нагромождением промежуточных слоёв, чья задача сводится лишь к тому, чтобы переливать из пустого в порожнее переформулировать базовые API в других терминах.

Исправление dimgel, :

Дело не в профите. Гугли:

  1. «anemic vs rich domain model» – попадёшь на статью Фаулера; её не читай! Он известный адепт rich, в чём сам открытым текстом признавался. А читай стародавние срачи на RSDN, особо обращая внимание на посты IT, Sinclair и другие с ненулевыми оценками. Причём там была традиционная забава: в каждом из этих срачей обязательно выносили Фаулера вперёд ногами. :)

  2. «heavy vs lightweight ORMs» – в принципе, идёт паровозом к предыдущему: в теории эти вещи ортогональны, но на практике они строго коррелируют: heavy ORM используют c rich domain model, lightweight ORM – с anemic. Тяжёлые ORM – это как раз JPA; лёгкие – LINQ.

  3. Ну и может про «JPA vs LINQ» чего полезного нагуглится. По крайней мере, насколько я могу судить, именно LINQ выпустил лёгкие ORM в массы; и жаверы с тех самых пор и страдают, что у них такого нет. Для scala есть несколько решений; из них SLICK от авторов самой скалы – говно.

Фух. думал, стошнит пока допишу: дюже много вдруг вспомнилось и из тех срачей, и из собственных экспериментов на тему «когда heavy ORM всё-таки полезны». Обсуждать подробности и тем более спорить желания не имею.

UPD: Впрочем, одну вещь таки-напишу: причина, по которой heavy ORM (hibernate, и основанный на нём стандарт JPA) столь сложны, что у многих вызывают законную ненависть, очень проста и С ГОРДОСТЬЮ описана в библии по хиберу: это «paradigm mismatch bridge». Т.е. мост между разными парадигмами представления данных: реляционной и сетью объектов. Для меня это вообще матерное словосочетание, потому как это целый класс идеальных в своей переусложнённости примеров «дырявой абстракции». К этому же классу, например, принадлежат ещё stateful web frameworks.

Отсюда я вывел простое правило: нужно работать как можно ближе к базовым используемым технологиям (relative database, stateless web), и не увлекаться нагромождением промежуточных слоёв, чья задача сводится лишь к тому, чтобы переливать из пустого в порожнее переформулировать базовые API в других терминах.

Исправление dimgel, :

Дело не в профите. Гугли:

  1. «anemic vs rich domain model» – попадёшь на статью Фаулера; её не читай! Он известный адепт rich, в чём сам открытым текстом признавался. А читай стародавние срачи на RSDN, особо обращая внимание на посты IT, Sinclair и другие с ненулевыми оценками. Причём там была традиционная забава: в каждом из этих срачей обязательно выносили Фаулера вперёд ногами. :)

  2. «heavy vs lightweight ORMs» – в принципе, идёт паровозом к предыдущему: в теории эти вещи ортогональны, но на практике они строго коррелируют: heavy ORM используют c rich domain model, lightweight ORM – с anemic. Тяжёлые ORM – это как раз JPA; лёгкие – LINQ (для scala есть несколько решений; из них SLICK от авторов самой скалы – говно).

  3. Ну и может про «JPA vs LINQ» чего полезного нагуглится. По крайней мере, насколько я могу судить, именно LINQ выпустил лёгкие ORM в массы; и жаверы с тех самых пор и страдают, что у них такого нет.

Фух. думал, стошнит пока допишу: дюже много вдруг вспомнилось и из тех срачей, и из собственных экспериментов на тему «когда heavy ORM всё-таки полезны». Обсуждать подробности и тем более спорить желания не имею.

UPD: Впрочем, одну вещь таки-напишу: причина, по которой heavy ORM (hibernate, и основанный на нём стандарт JPA) столь сложны, что у многих вызывают законную ненависть, очень проста и С ГОРДОСТЬЮ описана в библии по хиберу: это «paradigm mismatch bridge». Т.е. мост между разными парадигмами представления данных: реляционной и сетью объектов. Для меня это вообще матерное словосочетание, потому как это целый класс идеальных в своей переусложнённости примеров «дырявой абстракции». К этому же классу, например, принадлежат ещё stateful web frameworks.

Отсюда я вывел простое правило: нужно работать как можно ближе к базовым используемым технологиям (relative database, stateless web), и не увлекаться нагромождением промежуточных слоёв, чья задача сводится лишь к тому, чтобы переливать из пустого в порожнее переформулировать базовые API в других терминах.

Исправление dimgel, :

Дело не в профите. Гугли:

  1. «anemic vs rich domain model» – попадёшь на статью Фаулера; её не читай! Он известный адепт rich, в чём сам открытым текстом признавался. А читай стародавние срачи на RSDN, особо обращая внимание на посты IT, Sinclair и другие с ненулевыми оценками. Причём там была традиционная забава: в каждом из этих срачей обязательно выносили Фаулера вперёд ногами. :)

  2. «heavy vs lightweight ORMs» – в принципе, идёт паровозом к предыдущему: в теории эти вещи ортогональны, но на практике они строго коррелируют: heavy ORM используют c rich domain model, lightweight ORM – с anemic. Тяжёлые ORM – это как раз JPA; лёгкие – LINQ (для scala есть несколько решений; из них SLICK от авторов самой скалы – говно).

  3. Ну и может про «JPA vs LINQ» чего полезного нагуглится. По крайней мере, насколько я могу судить, именно LINQ выпустил лёгкие ORM в массы; и жаверы с тех самых пор и страдают, что у них такого нет.

Фух. думал, стошнит пока допишу: дюже много вдруг вспомнилось и из тех срачей, и из собственных экспериментов на тему «когда heavy ORM всё-таки полезны». Обсуждать подробности и тем более спорить желания не имею.

UPD: Впрочем, одну вещь таки-напишу: причина, по которой heavy ORM (hibernate, и основанный на нём стандарт JPA) столь сложны, что у многих вызывают законную ненависть, очень проста и С ГОРДОСТЬЮ описана в библии по хиберу: это «paradigm mismatch bridge». Т.е. мост между разными парадигмами представления данных: реляционной и сетью объектов. Для меня это вообще матерное словосочетание, потому как это целый класс идеальных в своей переусложнённости примеров «дырявой абстракции». К этому же классу, например, принадлежат ещё stateful web frameworks.

Отсюда я вывел простое правило: нужно работать как можно ближе к базовым используемым технологиям (relative database, stateless web), и не увлекаться нагромождением промежуточных слоёв, чья задача сводится лишь к тому, чтобы переливать из пустого в порожнее переформулировать базовые API в других терминах.

Исправление dimgel, :

Дело не в профите. Гугли:

  1. «anemic vs rich domain model» – попадёшь на статью Фаулера; её не читай! Он известный адепт rich, в чём сам открытым текстом признавался. А читай стародавние срачи на RSDN, особо обращая внимание на посты IT, Sinclair и другие с ненулевыми оценками. Причём там была традиционная забава: в каждом из этих срачей обязательно выносили Фаулера вперёд ногами. :)

  2. «heavy vs lightweight ORMs» – в принципе, идёт паровозом к предыдущему: в теории эти вещи ортогональны, но на практике они строго коррелируют: heavy ORM используют c rich domain model, lightweight ORM – с anemic. Тяжёлые ORM – это как раз JPA; лёгкие – LINQ (для scala есть несколько решений; из них SLICK от авторов самой скалы – говно).

  3. Ну и может про «JPA vs LINQ» чего полезного нагуглится. По крайней мере, насколько я могу судить, именно LINQ выпустил лёгкие ORM в массы; и жаверы с тех самых пор и страдают, что у них такого нет.

Фух. думал, стошнит пока допишу: дюже много вдруг вспомнилось и из тех срачей, и из собственных экспериментов на тему «когда heavy ORM всё-таки полезны». Обсуждать подробности и тем более спорить желания не имею.

UPD: Впрочем, одну вещь таки-напишу: причина, по которой heavy ORM (hibernate, и основанный на нём стандарт JPA) столь сложны, что у многих вызывают законную ненависть, очень проста и С ГОРДОСТЬЮ описана в библии по хиберу: это «paradigm mismatch bridge». Т.е. мост между разными парадигмами представления данных: реляционной и сетью объектов. Для меня это вообще матерное словосочетание, потому как это целый класс идеальных в своей переусложнённости примеров «дырявой абстракции». К этому же классу, например, принадлежат ещё stateful web frameworks.

Исправление dimgel, :

Дело не в профите. Гугли:

  1. «anemic vs rich domain model» – попадёшь на статью Фаулера; её не читай! Он известный адепт rich, в чём сам открытым текстом признавался. А читай стародавние срачи на RSDN, особо обращая внимание на посты IT, Sinclair и другие с ненулевыми оценками. Причём там была традиционная забава: в каждом из этих срачей обязательно выносили Фаулера вперёд ногами. :)

  2. «heavy vs lightweight ORMs» – в принципе, идёт паровозом к предыдущему: в теории эти вещи ортогональны, но на практике они строго коррелируют: heavy ORM используют c rich domain model, lightweight ORM – с anemic. Тяжёлые ORM – это как раз JPA; лёгкие – LINQ (для scala есть несколько решений; из них SLICK от авторов самой скалы – говно).

  3. Ну и может про «JPA vs LINQ» чего полезного нагуглится. По крайней мере, насколько я могу судить, именно LINQ выпустил лёгкие ORM в массы; и жаверы с тех самых пор и страдают, что у них такого нет.

Фух. думал, стошнит пока допишу: дюже много вдруг вспомнилось и из тех срачей, и из собственных экспериментов на тему «когда heavy ORM всё-таки полезны». Обсуждать подробности и тем более спорить желания не имею.

UPD: Впрочем, одну вещь таки-напишу: причина, по которой rich ORM (hibernate, и основанный на нём стандарт JPA) столь сложны, что у многих вызывают законную ненависть, очень проста и С ГОРДОСТЬЮ описана в библии по хиберу: это «paradigm mismatch bridge». Т.е. мост между разными парадигмами представления данных: реляционной и сетью объектов. Для меня это вообще матерное словосочетание, потому как это целый класс идеальных в своей переусложнённости примеров «дырявой абстракции». К этому же классу, например, принадлежат ещё stateful web frameworks.

Исходная версия dimgel, :

Дело не в профите. Гугли:

  1. «anemic vs rich domain model» – попадёшь на статью Фаулера; её не читай! Он известный адепт rich, в чём сам открытым текстом признавался. А читай стародавние срачи на RSDN, особо обращая внимание на посты IT, Sinclair и другие с ненулевыми оценками. Причём там была традиционная забава: в каждом из этих срачей обязательно выносили Фаулера вперёд ногами. :)

  2. «heavy vs lightweight ORMs» – в принципе, идёт паровозом к предыдущему: в теории эти вещи ортогональны, но на практике они строго коррелируют: heavy ORM используют c rich domain model, lightweight ORM – с anemic. Тяжёлые ORM – это как раз JPA; лёгкие – LINQ (для scala есть несколько решений; из них SLICK от авторов самой скалы – говно).

  3. Ну и может про «JPA vs LINQ» чего полезного нагуглится. По крайней мере, насколько я могу судить, именно LINQ выпустил лёгкие ORM в массы; и жаверы с тех самых пор и страдают, что у них такого нет.

Фух. думал, стошнит пока допишу: дюже много вдруг вспомнилось и из тех срачей, и из собственных экспериментов на тему «когда heavy ORM всё-таки полезны». Обсуждать подробности и тем более спорить желания не имею.