Ok, je sais que je pourrais être downvoted dans l'oubli pour cette question, en particulier compte tenu de ma position sur la question, mais j'ai vraiment besoin de voir certains honnête, attentionné débat sur les mérites de la actuellement accepté d'applications d'entreprise paradigme de conception.
Je ne suis pas convaincu que les objets de l'entité doit exister.
Par les objets de l'entité, je veux dire les choses typiques que nous avons tendance à construire pour nos applications, comme "Personne", "Compte", "Ordre", etc.
Ma conception de la philosophie est la suivante:
- Tous les accès de base de données doit être accomplie à l'aide de procédures stockées.
- Chaque fois que vous avez besoin de données, appeler une procédure stockée et itérer sur un SqlDataReader ou les lignes dans un DataTable
(Note: j'ai aussi construit des applications d'entreprise avec Java EE, java gens veuillez remplacer les equvalent pour mon .NET des exemples)
Je ne suis pas anti-OO. J'écris beaucoup de classes à des fins différentes, pas seulement des entités. J'admets que une grande partie des classes que j'écris sont statiques des classes d'assistance.
Je ne suis pas des jouets de construction. Je parle de grand volume transactionnel des applications déployées sur plusieurs machines. Les applications Web, les services de windows, web services, b2b interaction, you name it.
J'ai utilisé OU Cartographes. J'ai écrit un peu. J'ai utilisé le Java EE de la pile, l'AAPC, et quelques autres équivalents. Je n'ai pas utilisé, mais activement développé et maintenu ces applications dans les environnements de production.
Je suis venu à la bataille testés conclusion que les objets de l'entité sont arriver dans notre direction et notre vie serait tellement plus facile sans eux.
Considérons ce simple exemple: vous recevez un appel de soutien sur une certaine page dans votre application qui ne fonctionne pas correctement, peut-être l'un des champs n'est pas persisté comme il le devrait. Avec mon modèle, le réalisateur attribué à trouver le problème s'ouvre exactement 3 fichiers. Un ASPX, un ASPX.CS et un fichier SQL avec la procédure stockée. Le problème, qui pourrait être un paramètre manquant à l'appel de procédure stockée, prend quelques minutes pour le résoudre. Mais avec n'importe quel modèle d'entité, vous aurez immanquablement de lancer le débogueur, commencer parcourant le code, et vous pouvez vous retrouver avec 15 à 20 fichiers ouvert dans Visual Studio. Par le temps que vous descendez au bas de la pile, vous avez oublié où vous avez commencé. Nous ne pouvons garder beaucoup de choses dans nos têtes à la fois. Le logiciel est incroyablement complexe, sans ajout de couches inutiles.
La complexité de développement et de dépannage sont juste à côté de mon seul reproche.
Maintenant, nous allons parler de l'évolutivité.
Les développeurs de réaliser que chaque fois qu'ils écrivent ou de modifier tout le code qui interagit avec la base de données, ils ont besoin de faire une analyse approfondie de l'impact exact sur la base de données? Et pas seulement le développement de la copie, je veux dire un synoptique de la production, de sorte que vous pouvez voir que la colonne supplémentaire vous maintenant besoin de votre objet juste la nullité de l'actuel plan de requête et d'un rapport qui a été exécuté en 1 seconde va maintenant prendre plus de 2 minutes, juste parce que vous avez ajouté une seule colonne à la liste de sélection? Et il s'avère que l'index vous maintenant besoin est si grand que l'administrateur va avoir à modifier l'agencement de vos fichiers?
Si vous laisser les gens s'éloignent trop de la physique de la banque de données avec une abstraction, ils vont faire des ravages avec une application qui a besoin à l'échelle.
Je ne suis pas un zélote. Je peux être convaincu si j'ai tort, et peut-être que je suis, étant donné qu'il existe une forte tendance à l'Linq to Sql, ADO.NET EF, Hibernate, Java EE, etc. Merci de penser à vos réponses, si je suis absent quelque chose que je veux vraiment savoir ce que c'est, et pourquoi je devrais changer ma façon de penser.
[Modifier]
Il ressemble à cette question est tout à coup de nouveau actif, alors, maintenant que nous avons la nouvelle fonctionnalité de commentaire j'ai commenté directement sur plusieurs réponses. Merci pour les réponses, je pense que c'est une bonne discussion.
J'ai probablement dû être plus clair que je suis en train de parler des applications d'entreprise. Je ne peux pas vraiment commenter, dire, un jeu qui tourne sur un bureau ou une application mobile.
Une chose que j'ai à mettre en place ici, en haut, en réponse à plusieurs des réponses similaires: orthogonalité et la séparation des préoccupations reçois souvent cités comme raisons d'aller de l'entité/ORM. Procédures stockées, pour moi, sont le meilleur exemple de la séparation des préoccupations que je peux penser. Si vous désactivez tous les autres accès à la base de données, autres que via des procédures stockées, vous pourriez en théorie refonte de l'ensemble de votre modèle de données et pour ne pas casser tout le code, tant que vous avez maintenu les entrées et les sorties des procédures stockées. Ils sont un parfait exemple de la programmation par contrat (si tant est que vous éviter un "select *" et de documenter le résultat des ensembles).
Demandez à quelqu'un qui a été dans l'industrie pendant un long moment et a travaillé avec les applications de longue durée: comment beaucoup d'application et de l'INTERFACE utilisateur couches sont venus et repartis, tandis qu'une base de données a vécu? Comment est-il difficile à régler et refactoriser une base de données lorsqu'il y a 4 ou 5 couches de persistance de la génération de SQL pour obtenir les données? Vous ne pouvez pas changer quoi que ce soit! Orm ou tout autre code qui génère le SQL de verrouillage de votre base de données dans la pierre.
