Je suis nouveau dans la CSLA et le cadre d'entité. Je crée une nouvelle application CSLA / Silverlight qui remplacera un système Win32 C ++ de 12 ans. L'ancien système utilise une bibliothèque d'objets Business personnalisée DCOM et utilise ODBC pour rejoindre SQL Server. Le nouveau système ne remplacera pas immédiatement l'ancien système - ils doivent coexister contre la même base de données depuis des années à venir.
Au début, je pensais que EF était la voie à suivre depuis que c'est le dernier et le plus grand. Après avoir effectué un petit modèle EF et seulement 2 objets racines modifiables CSLA (je vais éventuellement avoir des centaines d'objets car mes dB disposent de 800 tables), je remets sérieusement l'utilisation de EF.
Dans le système actuel, j'ai besoin de plusieurs reprises pour faire un réglage de performance de détail fin des requêtes que je peux faire en raison de la commande à 100% du SQL généré. Mais cela semble en EF que cela se passe tellement dans les coulisses que je perds ce contrôle. Article comme http://taoomanylayers.blogspot.com /2009/01/entity-Framework-and-linq-to-sql.html N'aidez pas mon impression d'EF.
Les gens semblent aimer EF à cause de LINQ à EF, mais depuis que mes critères sont passés entre le client et le serveur comme objet de critères, il semble que je puisse construire des requêtes tout aussi facilement sans linq. Je comprends dans WCF RIA qu'il existe une projection de requête (ou quelque chose comme ça) où je peux faire le côté client LINQ, qui passe au serveur avant la Traduction en SQL réel, donc dans ce cas, je peux voir l'avantage de EF, mais pas en CSLA .
Si j'utilise brut ado.net, vais-je regretter ma décision 5 ans à partir de maintenant?
Quelqu'un d'autre a-t-il fait ce choix récemment et de quelle manière êtes-vous allé?
3 Réponses :
Dans votre cas, je choisirais toujours EF de le faire tout à la main.
pourquoi? EF - en particulier dans .NET 4 - a considérablement mûri. Il vous permettra de faire la plupart de vos opérations de base de données beaucoup plus facilement et avec beaucoup moins de code que si vous avez à tous les codes de main, votre code d'accès aux données.
Et dans les cas où vous avez besoin de performances maximales absolues, vous pouvez toujours brancher des procédures stockées pour insertion, la mise à jour, supprimer que EF4 utilisera ensuite au lieu du comportement par défaut de la création des relevés SQL à la volée.
EF4 a une intégration de la procréation bien stockée, et cela ouvre vraiment le meilleur des deux mondes:
Voir certaines ressources:
Vous semblez avoir un mélange d'exigences et un mélange de solutions.
I Normalement évaluez chaque exigence avec un essentiel, agréable à avoir, pas indispensable. Et puis voir ce qui fonctionne.
Je suis d'accord avec ce que @ Marc_s a dit, vous pouvez avoir le meilleur des deux mondes.
La seule autre chose que je dirais, c'est que si cette solution doit être autour des 5 prochaines années, avez-vous envisagé des tests unitaires?
Il y a beaucoup de Exemples sur la manière de la configurer à l'aide de EF. (Personnellement, évitez Ado.net simplement parce que la séparation des préoccupations est tellement compliquée pour les tests d'unités.)
Il n'y a pas de solution facile. Je choisirais une fonctionnalité de votre projet qui vous mènerait un jour ou pour le faire. Essayez les différentes méthodes (SQL RAW, EF, EF + stocké des PROC) et voyez ce qui fonctionne!
Prendre un objectif objectif sur CSLA - appelez "Dataportal" et consultez la pile d'appels.
Ensuite, mettez ces classes sur un serveur de construction CI qui stocke des données d'exécution et fournit un tracé de dispersion sur une série de pistes.
Suivant, regardez le code qui est créé. Demandez-vous comment vous pouvez utiliser des choses telles que la dépendance injection à la lumière des classes qui s'appuient sur des créateurs statiques avec des constructeurs protégés / privés.
Ensuite, jetez un coup d'œil au nombre de responsabilités des classes «CSLA».
Enfin, demandez-vous si la création d'objets avec différents constructeurs par environnement a du sens et demandez-vous comment vous allez tester ces éléments.
Vous semblez ne pas aimer CSLA pour des raisons valables et certaines ne sont pas si valables dans mon cas. Que recommandez-vous pour une framework de bus obj qui a: convivialité de Silverlight et .NET (WebForms, Winforms, WPF, SOA sur mesure), des règles côté serveur et du client (utilisateur configurable et codé dur), utilisateur configurable par propriété / par Contrôle de sécurité CRUD, utilisateur configurable par des valeurs de champ de la propriété par défaut et divers déploiements N-TIER pour travailler dans différents environnements clients. J'ai besoin de tout cela et plus. Je construis une application non pas un cadre et je ne veux rien réinventer. Suggestions? Merci.
Je ne suis pas sûr de ce que vous entendez par «n'aime pas CSLA». Code est code. J'ai pris votre question initiale sur la CSLA et l'EF, mais le libellé de vos exigences montrent que vous êtes déjà adapté au problème de la CSLA Vernaculaire.
Grande question ... J'étais sur le point de demander un très similaire. Je me suis demandé quel est l'avantage de EF sur la vitesse et le contrôle de Ado.net ...