J'ai lu ce post hier soir, et j'ai remarqué que c'était en 2006. Je pouvais aller dans les deux sens sur l'ORM, la base de données, mais je me demandais simplement si tout ce que Jeff a dit à propos d'ORM s'applique toujours, étant donné que le post date de 2006.
Réponses
Trop de publicités?
C'est toujours vrai.
Plus encore que OO logiciel, la base de données souffre si elle n'est pas traitée précisément le sens souhaité. Et ce n'était pas prévu que vous devriez interposer un peu d'abstraction de la couche en face d'elle.
Je pense imperméable couches d'abstraction que d'essayer de construire un Lego château, avec toutes les pièces fermées dans une taie d'oreiller. SQL est sacrément difficile de le faire correctement. Il ne partage pas beaucoup de motifs avec de la programmation procédurale, et les meilleures pratiques pour l'un peut être l'inverse pour les autres. Vous devez être en mesure d'analyser chaque élément dans une instruction SQL, et ont une assez bonne idée de ce que c'est l'intention de faire, et ce qu'il fait.
Beaucoup de gens semblent penser que, comme les fers à cheval, à proximité est assez bon - si la bonne réponse apparaît, cela implique que vous y êtes presque. En SQL, c'est tout simplement pas vrai.
RoR et l'ActiveRecord modèle ont juste gagné une réputation comme l'un sgbd de la surconsommation des ressources pour cette raison. Optimisé ActiveRecord de conception est le plus souvent sous-optimale SQL conception, parce qu'il encourage l'instruction SQL de la décomposition.
Bill Karwin
Points
204877
Oui.
Orientée objet est toujours orientée objet et Relationnel est toujours orientée sur un Ensemble. Rien n'a changé dans ces deux paradigmes dans les deux dernières années afin de les faire mieux travailler ensemble.
Dans les yeux de nombreuses personnes, SQL, c'est moche, complexe et déroutant. Mais essayer de faire une interface orientée objet pour effectuer la même fonctionnalité est toujours plus laid, de plus en plus complexe, et a un plus raide de la courbe d'apprentissage.
Dans l'ensemble de la programmation, il est nécessaire de trouver un compromis entre la souplesse et à des hypothèses. Cadres (tels que des Rails, essayez de résoudre le problème en étant "d'opinions." Qui est, ils limitent la flexibilité de la ou relationnelle orientée objet, les aspects du problème, de faire des hypothèses sur la façon dont les données sont structurées, et quelles sont les opérations que vous pouvez faire avec lui. Naturellement, de simplifier le problème de l'espace rend la solution plus simple.
En outre, il est frustrant de découvrir qu'un ORM est incomplète, de sorte que certaines activités ordinaires dans SQL ont pas de solution dans un ORM. C'est aussi une conséquence de la "opinions" des cadres.
Otávio Décio
Points
44200
Je ne peux parler que de mon expérience. J'utilise DAL et DTO, et je suis toujours capable d'effectuer des requêtes assez complexes (jointures et tout), et je suis également en mesure de recourir à des SP ou à du SQL personnalisé chaque fois que j'en ai besoin. Cela m'a rendu la vie plus facile, mon code cohérent et mes délais plus accessibles.
davetron5000
Points
9622
Je pense que partant de l'hypothèse que Jeff conclusions sont correctes n'est pas nécessairement une bonne chose; avoir maintenu code de procédure stockée ainsi que JDBC à base de couches de données, je peux dire que ces causé des problèmes de maintenance à gogo, pour la plupart liés à l'incapacité de comprendre ce qui se passe à un niveau supérieur.
Une base de données est nécessairement faible niveau; il stocke les nombres et les chaînes de caractères essentiellement. La logique métier est de haut niveau. C'est pourquoi nous avons l'abstraction.
Personnellement, je pense que les Rails/ActiveRecord façon est la meilleure solution pour avoir un objet/modèle du domaine, mais aussi être en mesure de profiter d'une base de données relationnelle.
Donc: ne pas jeter de l'ORM, mais ne le font pas défaut non plus. C'est un outil qui permet de résoudre certains problèmes. L'ignorer serait ignorants et de toujours utiliser il serait arrogant.
