Сила ORM заключается в том, что он позволяет моделировать поведение приложения, используя объектно-ориентированные методы. В тщательно спроектированном мире у вас есть один уровень приложения, в котором язык бизнеса точно соответствует языку команды разработчиков. ORM является активатором этого, если ORM используется разумно.
Слабость в том, что количество людей, которые действительно, действительно, получают объектно-ориентированное программирование, довольно мало. Многие люди пишут спагетти и фрикадельки, с сильно связанными объектами, которые не имеют своего собственного поведения, а фактическое поведение заканчивается в отвратительных 8000-строчных классах «Service» и «Manager», и этот код часто настолько запутан, что все боятся изменить его, потому что они не могут понять, какими будут побочные эффекты.
Кроме того, многие люди не получают реляционную модель. ORM не поможет им получить это, и это не поможет им, абстрагируя реляционную модель. Это просто позволяет вам сосредоточиться на своем доменном уровне на раннем этапе и получить это прямо перед тем, как вы начнете слишком беспокоиться о дизайне базы данных. При правильном применении с помощью разумных инструментов миграции схем ORM может помочь вам предотвратить накопление долгов кода.
Я создал приложения, в которых ORM делал код приложения простым, читаемым и тестируемым, и имел приемлемую производительность. Я также поддерживал приложения, в которых шаблон использовался неправильно, а код был сложным, непроверяемым, медленным и хрупким; оказывается, что сама ORM не имеет к этому никакого отношения, за исключением того, что вместо написания плохого кода, который плохо моделирует область приложения, устаревшая команда инженеров написала плохой код, который плохо смоделировал область приложения И плохой код уровня обслуживания, который пренебрег всем значение, которое их ORM может предоставить им.
ORM не сделают вас умнее, но в руках правильного разработчика могут привести к более удобному и качественному коду.