Pourquoi avons-nous besoin d'objets d'entité? [fermé]

J'ai vraiment besoin de voir un débat honnête et réfléchi sur les mérites du paradigme de conception d' applications d'entreprise actuellement accepté .

Je ne suis pas convaincu que les objets entité devraient exister.

Par objets d'entité, j'entends les éléments typiques que nous avons tendance à créer pour nos applications, comme "Personne", "Compte", "Commande", etc.

Ma philosophie de conception actuelle est la suivante:

• Tout accès à la base de données doit être effectué via des procédures stockées.
• Chaque fois que vous avez besoin de données, appelez une procédure stockée et itérez sur un SqlDataReader ou les lignes d'un DataTable

(Remarque: j'ai également construit des applications d'entreprise avec Java EE, les gens de Java veuillez remplacer l'équivalent pour mes exemples .NET)

Je ne suis pas anti-OO. J'écris beaucoup de classes à des fins différentes, mais pas des entités. J'admets qu'une grande partie des classes que j'écris sont des classes d'assistance statiques.

Je ne construis pas de jouets. Je parle d'applications transactionnelles volumineuses et volumineuses déployées sur plusieurs machines. Applications Web, services Windows, services Web, interaction b2b, vous l'appelez.

J'ai utilisé des OR Mappers. J'en ai écrit quelques-uns. J'ai utilisé la pile Java EE, CSLA et quelques autres équivalents. Je les ai non seulement utilisés, mais activement développé et maintenu ces applications dans des environnements de production.

J'en suis venu à la conclusion éprouvée au combat que les objets d'entité nous gênent et que nos vies seraient tellement plus faciles sans eux.

Prenons cet exemple simple: vous recevez un appel d'assistance concernant une certaine page de votre application qui ne fonctionne pas correctement, peut-être que l'un des champs n'est pas conservé comme il se doit. Avec mon modèle, le développeur chargé de trouver le problème ouvre exactement 3 fichiers . Un ASPX, un ASPX.CS et un fichier SQL avec la procédure stockée. Le problème, qui peut être un paramètre manquant à l'appel de procédure stockée, prend quelques minutes à résoudre. Mais avec n'importe quel modèle d'entité, vous lancerez invariablement le débogueur, commencerez à parcourir le code et vous pourrez vous retrouver avec 15 à 20 fichiers ouverts dans Visual Studio. Au moment où vous descendez au bas de la pile, vous avez oublié où vous avez commencé. Nous ne pouvons garder que tant de choses dans nos têtes à la fois. Le logiciel est incroyablement complexe sans ajouter de couches inutiles.

La complexité du développement et le dépannage ne sont qu'un côté de mon problème.

Parlons maintenant d'évolutivité.

Les développeurs se rendent-ils compte que chaque fois qu'ils écrivent ou modifient un code qui interagit avec la base de données, ils doivent faire une analyse approfondie de l'impact exact sur la base de données? Et pas seulement la copie de développement, je veux dire une imitation de la production, vous pouvez donc voir que la colonne supplémentaire dont vous avez maintenant besoin pour votre objet vient d'invalider le plan de requête actuel et un rapport qui s'exécutait en 1 seconde prendra maintenant 2 minutes, juste parce que vous avez ajouté une seule colonne à la liste de sélection? Et il s'avère que l'index dont vous avez maintenant besoin est si grand que le DBA va devoir modifier la disposition physique de vos fichiers?

Si vous laissez les gens s'éloigner trop du magasin de données physique avec une abstraction, ils créeront des ravages avec une application qui doit évoluer.

Je ne suis pas un fanatique. Je peux être convaincu si je me trompe, et peut-être que je le suis, car il y a une telle poussée vers Linq vers Sql, ADO.NET EF, Hibernate, Java EE, etc. Veuillez réfléchir à vos réponses, s'il me manque quelque chose, je veux vraiment savoir ce que c'est, et pourquoi je devrais changer ma façon de penser.

[Éditer]

Il semble que cette question est soudainement à nouveau active, alors maintenant que nous avons la nouvelle fonctionnalité de commentaire, j'ai commenté directement plusieurs réponses. Merci pour les réponses, je pense que c'est une discussion saine.

J'aurais probablement dû être plus clair que je parle d'applications d'entreprise. Je ne peux vraiment pas commenter, par exemple, un jeu qui s'exécute sur le bureau de quelqu'un ou une application mobile.

Une chose que je dois mettre ici en haut en réponse à plusieurs réponses similaires: l'orthogonalité et la séparation des préoccupations sont souvent citées comme des raisons d'aller entité / ORM. Les procédures stockées sont pour moi le meilleur exemple de séparation des préoccupations auquel je puisse penser. Si vous interdisez tout autre accès à la base de données, autrement que via des procédures stockées, vous pourriez en théorie reconcevoir l'ensemble de votre modèle de données et ne casser aucun code, à condition de conserver les entrées et les sorties des procédures stockées. Ils sont un parfait exemple de programmation par contrat (à condition d'éviter de "sélectionner *" et de documenter les jeux de résultats).

Demandez à quelqu'un qui travaille dans l'industrie depuis longtemps et qui a travaillé avec des applications à longue durée de vie: combien de couches d'applications et d'interface utilisateur se sont succédées alors qu'une base de données vivait? À quel point est-il difficile d'ajuster et de refactoriser une base de données alors qu'il existe 4 ou 5 couches de persistance différentes générant du SQL pour obtenir les données? Vous ne pouvez rien changer! Les ORM ou tout code générant du SQL verrouillent votre base de données dans la pierre .

Je pense que cela dépend de la complexité de la «logique» de l'application et de l'endroit où vous l'avez implémentée. Si toute votre logique est dans des procédures stockées et que votre application ne fait qu'appeler ces procédures et afficher les résultats, le développement d'objets d'entité est en effet une perte de temps. Mais pour une application où les objets ont des interactions riches les uns avec les autres, et la base de données n'est qu'un mécanisme de persistance, il peut être utile d'avoir ces objets.

Donc, je dirais qu'il n'y a pas de réponse unique. Les développeurs doivent être conscients que, parfois, essayer d'être trop OO peut causer plus de problèmes qu'il n'en résout.

La théorie dit que des implémentations hautement cohésives et faiblement couplées sont la voie à suivre.

Je suppose donc que vous remettez en question cette approche, à savoir la séparation des préoccupations.

Mon fichier aspx.cs doit-il interagir avec la base de données, appeler un sproc et comprendre IDataReader?

Dans un environnement d'équipe, en particulier lorsque vous avez des personnes moins techniques qui s'occupent de la partie aspx de l'application, je n'ai pas besoin que ces personnes soient capables de "toucher" ce truc.

Séparer mon domaine de ma base de données me protège des changements structurels dans la base de données, sûrement une bonne chose? Bien sûr, l'efficacité de la base de données est absolument importante, alors laissez quelqu'un qui est le plus excellent dans ce domaine s'occuper de cela, en un seul endroit, avec le moins d'impact possible sur le reste du système.

À moins que je ne comprenne mal votre approche, un changement structurel dans la base de données pourrait avoir un impact important sur la surface de votre application. Je vois que cette séparation des préoccupations me permet, à moi et à mon équipe, de minimiser cela. De plus, tout nouveau membre de l'équipe devrait mieux comprendre cette approche.

De plus, votre approche semble préconiser que la logique métier de votre application réside dans votre base de données? Cela me semble faux, SQL est vraiment bon pour interroger les données et non, à mon humble avis, pour exprimer la logique métier.

Pensée intéressante cependant, même si elle me semble à un pas de SQL dans l'aspx, qui, depuis mes mauvais jours asp non structurés, me remplit d'effroi.

Une raison - séparer votre modèle de domaine de votre modèle de base de données.

Ce que je fais, c'est utiliser le développement piloté par les tests, donc j'écris d'abord mes couches d'interface utilisateur et de modèle et la couche de données est simulée, de sorte que l'interface utilisateur et le modèle sont construits autour d'objets spécifiques au domaine, puis plus tard, je mappe ces objets à la technologie que j'utilise la couche de données. C'est une mauvaise idée de laisser la structure de la base de données déterminer la conception de votre application. Dans la mesure du possible, écrivez d'abord l'application et laissez cela influencer la structure de votre base de données, et non l'inverse.

Pour moi, cela revient à ne pas vouloir que mon application se préoccupe de la façon dont les données sont stockées. Je vais probablement être giflé pour avoir dit cela ... mais votre application ne sont pas vos données, les données sont un artefact de l'application. Je veux que mon application réfléchisse en termes de clients, commandes et articles, pas une technologie comme DataSets, DataTables et DataRows ... car qui sait combien de temps ils dureront.

Je conviens qu'il y a toujours une certaine quantité de couplage, mais je préfère que ce couplage atteigne vers le haut plutôt que vers le bas. Je peux modifier les branches et les feuilles d'un arbre plus facilement que de modifier son tronc.

J'ai tendance à réserver les sprocs pour les rapports car les requêtes ont tendance à être un peu plus méchantes que l'accès aux données générales des applications.

J'ai aussi tendance à penser qu'avec des tests unitaires appropriés au début de ce scénario, c'est comme si une colonne n'étant pas persistante ne sera probablement pas un problème.

Eric, tu es mort. Pour toute application vraiment évolutive / facile à entretenir / robuste, la seule vraie réponse est de se passer de toutes les ordures et de s'en tenir aux bases.

J'ai suivi une trajectoire similaire avec ma carrière et suis arrivé aux mêmes conclusions. Bien sûr, nous sommes considérés comme des hérétiques et regardés drôle. Mais mes affaires fonctionnent et fonctionnent bien.

Chaque ligne de code doit être considérée avec suspicion.

Je voudrais répondre par un exemple similaire à celui que vous avez proposé.

Dans mon entreprise, j'ai dû créer une simple section CRUD pour les produits, je construis toutes mes entités et un DAL séparé. Plus tard, un autre développeur a dû modifier une table associée et il a même renommé plusieurs champs. Le seul fichier que j'ai dû modifier pour mettre à jour mon formulaire était le DAL de cette table.

Ce que (à mon avis) les entités apportent à un projet est:

Ortogonalité: les changements dans une couche peuvent ne pas affecter les autres couches (bien sûr, si vous apportez un changement important à la base de données, cela se répercuterait sur toutes les couches, mais la plupart des petits changements ne le seront pas).

Testabilité: vous pouvez tester votre logique sans toucher à votre base de données. Cela augmente les performances de vos tests (vous permettant de les exécuter plus fréquemment).

Séparation des préoccupations: Dans un gros produit, vous pouvez attribuer la base de données à un DBA et il peut en optimiser l'enfer. Attribuez le modèle à un expert métier qui possède les connaissances nécessaires pour le concevoir. Attribuez des formulaires individuels à des développeurs plus expérimentés sur les formulaires Web, etc.

Enfin, j'aimerais ajouter que la plupart des mappeurs ORM prennent en charge les procédures stockées puisque c'est ce que vous utilisez.

À votre santé.

Je pense que vous «mordez plus que vous ne pouvez mâcher» sur ce sujet. Ted Neward n'était pas désinvolte lorsqu'il l'appelait le « Vietnam de l'informatique ».

Une chose que je peux absolument vous garantir est que cela ne changera le point de vue de personne sur la question, comme cela a été prouvé si souvent sur d'innombrables autres blogs, forums, podcasts, etc.

C'est certainement normal d'avoir une discussion ouverte et un débat sur un sujet controversé, c'est juste que celui-ci a été fait tellement de fois que les deux «côtés» ont accepté de ne pas être d'accord et se sont juste mis à écrire un logiciel.

Si vous souhaitez approfondir votre lecture des deux côtés, consultez les articles sur le blog de Ted, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans, etc.

@Dan, désolé, ce n'est pas le genre de chose que je recherche. Je connais la théorie. Votre déclaration "est une très mauvaise idée" n'est pas étayée par un exemple réel. Nous essayons de développer des logiciels en moins de temps, avec moins de personnel, avec moins d'erreurs, et nous voulons pouvoir apporter des modifications facilement. Votre modèle multicouche, d'après mon expérience, est négatif dans toutes les catégories ci-dessus. Surtout pour faire du modèle de données la dernière chose que vous faites. Le modèle de données physiques doit être une considération importante dès le premier jour.

J'ai trouvé votre question vraiment intéressante.
En général, j'ai besoin d'objets entités pour encapsuler la logique métier d'une application. Ce serait vraiment compliqué et inadéquat de pousser cette logique dans la couche de données.
Que feriez-vous pour éviter ces objets entités? Quelle solution avez-vous en tête?

Les objets d'entité peuvent faciliter la mise en cache sur la couche d'application. Bonne chance pour la mise en cache d'un lecteur de données.

Nous devrions également parler de la notion de ce que sont réellement les entités. Quand je lis cette discussion, j'ai l'impression que la plupart des gens ici regardent les entités dans le sens d'un modèle de domaine anémique . Beaucoup de gens considèrent le modèle de domaine anémique comme un anti-modèle!

Il y a de la valeur dans les modèles de domaines riches. C'est ce qu'est le Domain Driven Design . Je pense personnellement que l'OO est un moyen de conquérir la complexité. Cela signifie non seulement une complexité technique (comme l'accès aux données, l'interface utilisateur, la sécurité ...) mais aussi une complexité dans le domaine métier !

Si nous pouvons appliquer des techniques OO pour analyser, modéliser, concevoir et implémenter nos problèmes métier, c'est un énorme avantage pour la maintenabilité et l'extensibilité des applications non triviales!

Il existe des différences entre vos entités et vos tables. Les entités doivent représenter votre modèle, les tableaux ne représentent que l'aspect données de votre modèle!

Il est vrai que les données vivent plus longtemps que les applications, mais considérez cette citation de David Laribee : Les modèles sont éternels ... les données sont un effet secondaire heureux.

Quelques liens supplémentaires sur ce sujet:

• Pourquoi Setters et Getters sont mauvais

• Retour d'OO pur

• POJO contre NOJO

• Super modèles partie 2

• TDD, maquette et conception

Question vraiment intéressante. Honnêtement, je ne peux pas prouver pourquoi les entités sont bonnes. Mais je peux partager mon opinion sur les raisons pour lesquelles je les aime. Code comme

void exportOrder(Order order, String fileName){...};

ne concerne pas la provenance de l'ordre - de la base de données, de la requête Web, du test unitaire, etc. Cela rend cette méthode plus explicitement déclarée exactement ce qu'elle nécessite, au lieu de prendre DataRow et de documenter les colonnes qu'elle s'attend à avoir et les types qu'elles devraient être. Il en va de même si vous l'implémentez d'une manière ou d'une autre en tant que procédure stockée - vous devez toujours lui envoyer l'ID d'enregistrement, alors qu'il n'est pas nécessaire qu'il soit présent dans la base de données.

La mise en œuvre de cette méthode serait effectuée sur la base de l'abstraction Order, et non sur la façon dont elle est présentée exactement dans DB. La plupart de ces opérations que j'ai implémentées ne dépendent vraiment pas de la façon dont ces données sont stockées. Je comprends que certaines opérations nécessitent un couplage avec la structure DB à des fins de performances et d'évolutivité, juste d'après mon expérience, il n'y en a pas trop. D'après mon expérience, très souvent, il suffit de savoir que Person a .getFirstName () renvoie String, et .getAddress () renvoie l'adresse, et que l'adresse a .getZipCode (), etc. - et ne se soucie pas des tables impliquées pour stocker ces données .

Si vous devez faire face à des problèmes comme vous l'avez décrit, comme lorsque la colonne supplémentaire rompt les performances du rapport, alors pour vos tâches, la base de données est une partie critique, et vous devriez en effet en être aussi proche que possible. Bien que les entités puissent fournir des abstractions pratiques, elles peuvent également masquer certains détails importants.

L'évolutivité est un point intéressant ici - la plupart des sites Web qui nécessitent une énorme évolutivité (comme facebook, livejournal, flickr) ont tendance à utiliser l'approche DB-ascétique, lorsque DB est utilisé aussi rare que possible et que les problèmes d'évolutivité sont résolus par la mise en cache, en particulier par l'utilisation de la RAM. http://highscalability.com/ contient des articles intéressants à ce sujet.

Il existe d'autres bonnes raisons pour les objets d'entité en plus de l'abstraction et du couplage lâche. L'une des choses que j'aime le plus est la frappe forte que vous ne pouvez pas obtenir avec un DataReader ou un DataTable. Une autre raison est que lorsqu'elles sont bien faites, les classes d'entités appropriées peuvent rendre le code plus maintenable en utilisant des constructions de première classe pour les termes spécifiques au domaine que quiconque regarde le code est susceptible de comprendre plutôt qu'un tas de chaînes avec des noms de champ utilisés. pour indexer un DataRow. Les procédures stockées sont vraiment orthogonales à l'utilisation d'un ORM car de nombreux frameworks de mappage vous donnent la possibilité de mapper sur des sprocs.

Je ne considérerais pas les sprocs + datareaders comme un substitut à un bon ORM. Avec les procédures stockées, vous êtes toujours contraint et étroitement couplé à la signature de type de la procédure, qui utilise un système de type différent du code appelant. Les procédures stockées peuvent être sujettes à modification pour prendre en charge des options supplémentaires et des changements de schéma. Une alternative aux procédures stockées dans le cas où le schéma est sujet à modification consiste à utiliser des vues - vous pouvez mapper des objets à des vues, puis remapper des vues aux tables sous-jacentes lorsque vous les modifiez.

Je peux comprendre votre aversion pour les ORM si votre expérience consiste principalement en Java EE et CSLA. Vous voudrez peut-être jeter un coup d'œil à LINQ to SQL, qui est un cadre très léger et est principalement un mappage un-à-un avec les tables de base de données, mais qui n'a généralement besoin que d'une extension mineure pour qu'ils deviennent des objets métier à part entière. LINQ to SQL peut également mapper des objets d'entrée et de sortie aux paramètres et résultats des procédures stockées.

La structure d'entité ADO.NET présente l'avantage supplémentaire que vos tables de base de données peuvent être affichées comme des classes d'entité héritant les unes des autres, ou comme des colonnes de plusieurs tables agrégées en une seule entité. Si vous devez modifier le schéma, vous pouvez modifier le mappage du modèle conceptuel vers le schéma de stockage sans modifier le code d'application réel. Et encore une fois, les procédures stockées peuvent être utilisées ici.

Je pense que plus de projets informatiques dans les entreprises échouent en raison d'une non-maintenabilité du code ou d'une faible productivité des développeurs (qui peut provenir, par exemple, d'un changement de contexte entre l'écriture de sproc et l'écriture d'applications) que des problèmes d'évolutivité d'une application.

Je voudrais également ajouter à la réponse de Dan que la séparation des deux modèles pourrait permettre à votre application d'être exécutée sur différents serveurs de base de données ou même sur des modèles de base de données.

Que faire si vous avez besoin de mettre à l'échelle votre application en équilibrant la charge de plusieurs serveurs Web? Vous pouvez installer l'application complète sur tous les serveurs Web, mais une meilleure solution consiste à faire en sorte que les serveurs Web parlent à un serveur d'applications.

Mais s'il n'y a pas d'objets d'entité, ils n'auront pas grand chose à dire.

Je ne dis pas que vous ne devriez pas écrire de monolithes s'il s'agit d'une application simple, interne et de courte durée. Mais dès que cela devient moyennement complexe, ou que cela devrait durer beaucoup de temps, vous devez vraiment penser à un bon design.

Cela permet de gagner du temps lors de sa maintenance.

En séparant la logique d'application de la logique de présentation et de l'accès aux données, et en passant des DTO entre eux, vous les découplez. Leur permettre de changer indépendamment.

Vous pourriez trouver ce post sur comp.object intéressant.

Je ne prétends pas être d'accord ou en désaccord mais c'est intéressant et (je pense) pertinent à ce sujet.

Une question: comment gérez-vous les applications déconnectées si toute votre logique métier est piégée dans la base de données?

Dans le type d'application d'entreprise qui m'intéresse, nous devons traiter plusieurs sites, certains d'entre eux doivent pouvoir fonctionner dans un état déconnecté.
Si votre logique métier est encapsulée dans une couche de domaine qui est simple à incorporer dans divers types d'applications - disons, en tant que dll- alors je peux créer des applications qui connaissent les règles métier et sont capables, si nécessaire, de les appliquer localement.

En conservant la couche Domaine dans les procédures stockées sur la base de données, vous devez vous en tenir à un seul type d'application qui a besoin d'une ligne de vue permanente sur la base de données.

C'est correct pour une certaine classe d'environnements, mais cela ne couvre certainement pas tout le spectre des applications d'entreprise .

@jdecuyper, une maxime que je me répète souvent est "si votre logique métier n'est pas dans votre base de données, ce n'est qu'une recommandation". Je pense que Paul Nielson a dit cela dans l'un de ses livres. Les couches d'application et l'interface utilisateur vont et viennent, mais les données durent généralement très longtemps.

Comment éviter les objets entité? Procédures stockées principalement. J'admets aussi librement que la logique métier a tendance à atteindre toutes les couches d'une application, que vous en ayez l'intention ou non. Un certain couplage est inhérent et inévitable.

J'ai beaucoup réfléchi à la même chose ces derniers temps; J'ai été un grand utilisateur de CSLA pendant un certain temps, et j'aime la pureté de dire que "toute votre logique métier (ou du moins autant que cela est raisonnablement possible) est encapsulée dans des entités commerciales".

J'ai vu le modèle d'entité commerciale apporter beaucoup de valeur dans les cas où la conception de la base de données est différente de la façon dont vous travaillez avec les données, ce qui est le cas dans de nombreux logiciels d'entreprise.

Par exemple, l'idée d'un «client» peut consister en un enregistrement principal dans une table Client, combiné avec toutes les commandes que le client a passées, ainsi que tous les employés du client et leurs coordonnées, et certaines des propriétés de un client et ses enfants peuvent être déterminés à partir des tables de recherche. C'est vraiment bien du point de vue du développement de pouvoir travailler avec le client en tant qu'entité unique, car d'un point de vue commercial, le concept de client contient toutes ces choses et les relations peuvent ou non être appliquées dans la base de données.

Bien que j'apprécie la citation selon laquelle "si votre règle métier n'est pas dans votre base de données, ce n'est qu'une suggestion", je pense également que vous ne devriez pas concevoir la base de données pour appliquer les règles métier, vous devez la concevoir pour qu'elle soit efficace, rapide et normalisée .

Cela dit, comme d'autres l'ont noté ci-dessus, il n'y a pas de «conception parfaite», l'outil doit s'adapter au travail. Mais l'utilisation d'entités commerciales peut vraiment aider à la maintenance et à la productivité, car vous savez où aller pour modifier la logique métier, et les objets peuvent modéliser des concepts réels de manière intuitive.

Eric,

Personne ne vous empêche de choisir le cadre / l'approche que vous souhaiteriez. Si vous allez suivre le chemin "piloté par les données / basé sur les procédures stockées", alors allez-y! Surtout si cela vous aide vraiment à livrer vos applications selon les spécifications et à temps.

La mise en garde étant (un revers à votre question), TOUTES vos règles métier doivent être sur des procédures stockées, et votre application n'est rien de plus qu'un client léger.

Cela étant dit, les mêmes règles s'appliquent si vous faites votre application en POO: soyez cohérent. Suivez les principes de la POO, et cela inclut la création d'objets d'entité pour représenter vos modèles de domaine.

La seule vraie règle ici est le mot cohérence . Personne ne vous empêche de vous concentrer sur DB. Personne ne vous empêche de suivre des programmes structurés à l'ancienne (c'est-à-dire fonctionnels / procéduraux). Merde, personne n'empêche quiconque de faire du code de style COBOL. MAIS une application doit être très, très cohérente une fois sur cette voie, si elle souhaite atteindre un degré de succès.

Je ne suis vraiment pas sûr de ce que vous considérez comme des «applications d'entreprise». Mais j'ai l'impression que vous le définissez comme une application interne où le SGBDR serait gravé dans le marbre et le système n'aurait pas à être interopérable avec d'autres systèmes, qu'ils soient internes ou externes.

Mais que se passe-t-il si vous aviez une base de données avec 100 tables, ce qui équivaut à 4 procédures stockées pour chaque table uniquement pour les opérations CRUD de base, soit 400 procédures stockées qui doivent être maintenues et ne sont pas fortement typées, donc sensibles aux fautes de frappe et ne peuvent pas être testées à l'unité . Que se passe-t-il lorsque vous obtenez un nouveau CTO qui est un évangéliste Open Source et veut changer le SGBDR de SQL Server à MySql?

Aujourd'hui, de nombreux logiciels, qu'il s'agisse d'applications ou de produits d'entreprise, utilisent SOA et ont certaines exigences pour exposer les services Web, du moins les logiciels que je suis et avec lesquels j'ai été impliqué. En utilisant votre approche, vous finiriez par exposer un DataTable ou DataRows sérialisé. Maintenant, cela peut être considéré comme acceptable si le client est garanti .NET et sur un réseau interne. Mais lorsque le client n'est pas connu, vous devez vous efforcer de concevoir une API intuitive et dans la plupart des cas, vous ne voudriez pas exposer le schéma de base de données complète. Je ne voudrais certainement pas expliquer à un développeur Java ce qu'est un DataTable et comment l'utiliser. Il y a aussi la prise en compte de la bande passante et de la taille de la charge utile et des DataTables sérialisés, les DataSets sont très lourds.

Il n'y a pas de solution miracle avec la conception de logiciels et cela dépend vraiment des priorités, pour moi, c'est dans un code testable à l'unité et des composants faiblement couplés qui peuvent être facilement utilisés par n'importe quel client.

juste mes 2 cents

Je voudrais offrir un autre angle au problème de la distance entre OO et RDB: l'histoire.

Tout logiciel a un modèle de réalité qui est dans une certaine mesure une abstraction de la réalité. Aucun programme informatique ne peut capturer toutes les complexités de la réalité, et les programmes sont écrits uniquement pour résoudre un ensemble de problèmes à partir de la réalité. Par conséquent, tout modèle logiciel est une réduction de la réalité. Parfois, le modèle logiciel force la réalité à se réduire. Par exemple, lorsque vous souhaitez que la société de location de voitures vous réserve une voiture tant qu'elle est bleue et qu'elle contient des alliages, mais que l'opérateur ne peut pas se conformer car votre demande ne rentre pas dans l'ordinateur.

RDB est issu d'une très ancienne tradition de mise en tables d'informations, appelée comptabilité. La comptabilité se faisait sur papier, puis sur cartes perforées, puis sur ordinateur. Mais la comptabilité est déjà une réduction de la réalité. La comptabilité a forcé les gens à suivre son système depuis si longtemps qu'il est devenu une réalité acceptée. C'est pourquoi il est relativement facile de créer un logiciel informatique pour la comptabilité, la comptabilité a eu son modèle d'information, bien avant l'arrivée de l'ordinateur.

Compte tenu de l'importance de bons systèmes comptables et de l'acceptation que vous obtenez de tous les chefs d'entreprise, ces systèmes sont devenus très avancés. Les bases de la base de données sont désormais très solides et personne n'hésite à conserver des données vitales dans quelque chose d'aussi fiable.

Je suppose que OO a dû arriver lorsque les gens ont découvert que d'autres aspects de la réalité sont plus difficiles à modéliser que la comptabilité (qui est déjà un modèle). OO est devenu une idée très réussie, mais la persistance des données OO est relativement sous-développée. RDB / Comptabilité a eu des gains faciles, mais OO est un domaine beaucoup plus vaste (essentiellement tout ce qui n'est pas comptable).

Beaucoup d'entre nous ont voulu utiliser OO, mais nous voulons toujours un stockage sécurisé de nos données. Quoi de plus sûr que de stocker nos données de la même manière que le fait le système comptable estimé? C'est une perspective séduisante, mais nous nous heurtons tous aux mêmes écueils. Très peu ont pris la peine de penser à la persistance OO par rapport aux efforts massifs de l'industrie RDB, qui a bénéficié de la tradition et de la position de la comptabilité.

Prevayler et db4o sont quelques suggestions, je suis sûr qu'il y en a d'autres dont je n'ai pas entendu parler, mais aucune n'a semblé obtenir la moitié de la presse comme, par exemple, l'hibernation.

Le stockage de vos objets dans de bons vieux fichiers ne semble même pas être pris au sérieux pour les applications multi-utilisateurs, et en particulier les applications Web.

Dans ma lutte quotidienne pour fermer le gouffre entre OO et RDB, j'utilise OO autant que possible, mais j'essaie de minimiser l'héritage. Je n'utilise pas souvent des SP. J'utiliserai les requêtes avancées uniquement dans les aspects qui ressemblent à la comptabilité.

Je serai heureusement surpris quand le gouffre sera fermé pour de bon. Je pense que la solution viendra quand Oracle lancera quelque chose comme "Oracle Object Instance Base". Pour vraiment faire son chemin, il devra avoir un nom rassurant.

Pas beaucoup de temps pour le moment, mais juste au-dessus de ma tête ...

Le modèle d'entité vous permet de donner une interface cohérente à la base de données (et à d'autres systèmes possibles) même au-delà de ce qu'une interface de procédure stockée peut faire. En utilisant des modèles commerciaux à l'échelle de l'entreprise, vous pouvez vous assurer que toutes les applications affectent les données de manière cohérente, ce qui est TRÈS important. Sinon, vous vous retrouvez avec de mauvaises données, ce qui est tout simplement un mal.

Si vous n'avez qu'une seule application, vous n'avez pas vraiment de système «d'entreprise», quelle que soit la taille de cette application ou de vos données. Dans ce cas, vous pouvez utiliser une approche similaire à celle dont vous parlez. Soyez simplement conscient du travail qui sera nécessaire si vous décidez de développer vos systèmes à l'avenir.

Voici cependant quelques points à garder à l'esprit (IMO):

1. Le code SQL généré est incorrect (exceptions à suivre). Désolé, je sais que beaucoup de gens pensent que c'est un gain de temps énorme, mais je n'ai jamais trouvé de système qui pourrait générer un code plus efficace que ce que je pourrais écrire et souvent le code est tout simplement horrible. Vous finissez également souvent par générer une tonne de code SQL qui n'est jamais utilisé. L'exception ici concerne les modèles très simples, comme peut-être les tables de consultation. Cependant, beaucoup de gens se laissent emporter.
2. Entités <> Tables (ou même des entités de modèle de données logiques nécessairement). Un modèle de données a souvent des règles de données qui doivent être appliquées aussi étroitement que possible à la base de données, ce qui peut inclure des règles sur la manière dont les lignes de table sont liées les unes aux autres ou d'autres règles similaires qui sont trop complexes pour l'IR déclarative. Ceux-ci doivent être traités dans des procédures stockées. Si toutes vos procédures stockées sont de simples processus CRUD, vous ne pouvez pas le faire. De plus, le modèle CRUD crée généralement des problèmes de performances car il ne minimise pas les allers-retours sur le réseau vers la base de données. C'est souvent le plus gros goulot d'étranglement dans une application d'entreprise.

Parfois, votre application et votre couche de données ne sont pas si étroitement couplées. Par exemple, vous pouvez avoir une application de facturation téléphonique. Vous créez plus tard une application distincte qui surveille l'utilisation du téléphone pour a) mieux vous annoncer b) optimiser votre forfait téléphonique.

Ces applications ont des préoccupations et des exigences de données différentes (même les données proviennent de la même base de données), elles conduiraient à des conceptions différentes. Votre base de code peut finir par un désordre absolu (dans l'une ou l'autre application) et un cauchemar à maintenir si vous laissez la base de données piloter le code.

Les applications dont la logique de domaine est séparée de la logique de stockage de données sont adaptables à tout type d'application de source de données (base de données ou autre) ou d'interface utilisateur (Web ou Windows (ou Linux, etc.)).

Vous êtes plutôt coincé dans votre base de données, ce qui n'est pas mal si vous êtes avec une entreprise qui est satisfaite du système de base de données actuel que vous utilisez. Cependant, étant donné que les bases de données évoluent au fil du temps, votre entreprise voudra peut-être utiliser un nouveau système de base de données vraiment soigné et nouveau. Et s'ils voulaient passer à une méthode d'accès aux données de services Web (comme le fait parfois l'architecture orientée services). Vous devrez peut-être porter vos procédures stockées partout.

De plus, la logique du domaine fait abstraction de l'interface utilisateur, ce qui peut être plus important dans les grands systèmes complexes qui ont des interfaces utilisateur en constante évolution (en particulier lorsqu'ils recherchent constamment plus de clients).

Aussi, même si je suis d'accord qu'il n'y a pas de réponse définitive à la question des procédures stockées par rapport à la logique de domaine. Je suis dans le camp de la logique de domaine (et je pense qu'ils gagnent avec le temps), car je pense que les procédures stockées élaborées sont plus difficiles à maintenir que la logique de domaine élaborée. Mais c'est un tout autre débat

Je pense que vous avez juste l'habitude d'écrire un type d'application spécifique et de résoudre un certain type de problème. Vous semblez attaquer cela du point de vue de la "base de données d'abord". Il existe de nombreux développeurs où les données sont conservées dans une base de données, mais les performances ne sont pas une priorité absolue. Dans de nombreux cas, mettre une abstraction sur la couche de persistance simplifie considérablement le code et le coût des performances n'est pas un problème.

Quoi que vous fassiez, ce n'est pas la POO. Ce n'est pas faux, ce n'est tout simplement pas de la POO, et il n'est pas logique d'appliquer vos solutions à tous les autres problèmes.

Question interessante. Quelques réflexions:

1. Comment feriez-vous un test unitaire si toute votre logique métier était dans votre base de données?
2. Les modifications apportées à la structure de votre base de données, en particulier celles qui affectent plusieurs pages de votre application, ne seraient-elles pas un problème majeur à changer dans l'application?

Bonne question!

Une approche que j'aime plutôt est de créer un objet itérateur / générateur qui émet des instances d'objets qui sont pertinents pour un contexte spécifique. Habituellement, cet objet encapsule des éléments d'accès à la base de données sous-jacents, mais je n'ai pas besoin de le savoir lors de son utilisation.

Par exemple,

Un objet AnswerIterator génère des objets AnswerIterator.Answer. Sous le capot, il itère une instruction SQL pour récupérer toutes les réponses et une autre instruction SQL pour récupérer tous les commentaires associés. Mais lors de l'utilisation de l'itérateur, j'utilise simplement l'objet Answer qui a les propriétés minimales pour ce contexte. Avec un peu de code squelette, cela devient presque trivial.

J'ai trouvé que cela fonctionne bien lorsque j'ai un énorme ensemble de données sur lequel travailler, et quand c'est bien fait, cela me donne de petits objets transitoires qui sont relativement faciles à tester.

C'est fondamentalement un placage mince sur le truc d'accès à la base de données, mais cela me donne toujours la flexibilité de l'abstraction quand j'en ai besoin.

Les objets de mes applications ont tendance à être liés un à un à la base de données, mais je trouve que l'utilisation de Linq To Sql plutôt que des sprocs facilite beaucoup l'écriture de requêtes compliquées, en particulier la possibilité de les créer à l'aide de l'exécution différée. par exemple de r dans Images.User.Ratings où etc. Cela m'évite d'essayer de travailler sur plusieurs instructions de jointure dans SQL, et avoir Skip & Take pour la pagination simplifie également le code plutôt que d'avoir à incorporer le row_number & 'over' code.

Pourquoi s'arrêter aux objets d'entité? Si vous ne voyez pas la valeur avec les objets d'entité dans une application de niveau entreprise, accédez simplement à vos données dans un langage purement fonctionnel / procédural et connectez-le à une interface utilisateur. Pourquoi ne pas simplement découper tous les "peluches" OO?