Question

La principale application Web de mon entreprise réclame un ensemble astucieux de bibliothèques pour la rendre d'une manière ou d'une autre maintenable et évolutive, et un de mes collègues a suggéré CSLA.J'ai donc acheté le livre mais comme :

les programmeurs ne lisent plus de livres

Je voulais connaître l'opinion de la communauté SOFlow à ce sujet.

Donc, voici mes questions:

  1. Comment les gens peuvent-ils utiliser CSLA ?
  2. Quels sont les avantages et inconvénients?
  3. Est-ce que CSLA ne cadre vraiment pas avec TDD ?
  4. Quelles sont mes alternatives ?
  5. Si vous avez arrêté de l’utiliser ou avez décidé de ne pas l’utiliser, pourquoi ?
Était-ce utile?

La solution

Avant de répondre spécifiquement à votre question, j'aimerais formuler quelques réflexions.CSLA est-il adapté à votre projet ?Ça dépend.Personnellement, je considérerais CSLA pour les applications de bureau qui ne valorisent pas les tests unitaires comme une priorité élevée.CSLA est idéal si vous souhaitez évoluer facilement vers une application à plusieurs niveaux.CSLA a tendance à être critiqué car il ne permet pas de tests unitaires purs.C'est vrai, mais comme pour toute chose en technologie, je crois qu'il y a Il n'y a pas une seule vraie voie.Les tests unitaires ne sont peut-être pas quelque chose que vous entreprenez pour un projet spécifique.Ce qui fonctionne pour une équipe et un projet peut ne pas fonctionner pour une autre équipe ou un autre projet.

Il existe également de nombreuses idées fausses concernant la CSLA.Ce n'est pas un ORM.ce n'est pas un concurrent de NHibernate (en fait, il utilise CLSA Business Objects et NHibernate car l'accès aux données s'accorde très bien).Il formalise le concept de Objet mobile.

1.Combien de personnes utilisent CSLA ?
Basé sur Forums CSLA, je dirais qu'il existe un certain nombre de projets basés sur CSLA.Honnêtement, je n’ai aucune idée du nombre de personnes qui l’utilisent réellement.Je l'ai utilisé dans le passé sur deux projets.

2.Quels sont les avantages et inconvénients?
Bien qu'il soit difficile de résumer dans une courte liste, voici quelques-uns des avantages et des inconvénients qui me viennent à l'esprit.
Avantages:

  • Il est facile de mettre les nouveaux développeurs au courant.Le livre CSLA et l'application d'exemples sont d'excellentes ressources pour se mettre au courant.
  • Le cadre de validation est véritablement de classe mondiale - et a été « emprunté » pour de nombreux autres projets et technologies non-CSLA.
  • Annulation au niveau n dans vos objets métier
  • Modification de la ligne de configuration pour l'évolutivité à n niveaux (Remarque :Pas même une recompilation n'est nécessaire)
  • Les technologies clés sont extraites du « vrai » code.Lorsque WCF a été introduit, il a eu un impact minimal sur le code CSLA.
  • Il est possible de partager vos objets métier entre fenêtres et projets web.
  • CSLA promeut la normalisation de comportement plutôt que la normalisation de données (quitter la base de données pour la normalisation des données).

Les inconvénients:

  • Difficulté dans les tests unitaires
  • Manque de séparation des préoccupations (généralement, vos objets métier contiennent un code d'accès aux données).
  • Alors que CSLA promeut la normalisation de comportement, plutôt que la normalisation de données, ce qui peut donner lieu à des objets métier portant des noms similaires, mais ayant des objectifs différents.Cela peut créer une certaine confusion et donner l’impression que vous ne réutilisez pas les objets de manière appropriée.Cela dit, une fois le saut physiologique franchi, cela a plus que du sens : il semble inapproprié de structurer les objets à l'ancienne.
  • Ce n'est pas "à la mode" de créer des applications de cette façon.Vous aurez peut-être du mal à trouver des développeurs passionnés par la technologie.

3.Après avoir lu ceci, CSLA ne cadre-t-il vraiment pas avec TDD ?
Je n'ai pas trouvé de moyen efficace de faire du TDD avec CSLA.Cela dit, je suis sûr qu’il y a beaucoup de gens plus intelligents que moi qui ont peut-être essayé cela avec plus de succès.

4.Quelles sont mes alternatives ?
La conception pilotée par domaine connaît actuellement un grand succès (et à juste titre - c'est fantastique pour certaines applications).Il existe également un certain nombre de modèles intéressants développés depuis l'introduction de LINQ (et LINQ to SQL, Entity Framework, etc.).Livre des Fowlers PoEAA, détaille de nombreux modèles qui peuvent convenir à votre application.Notez que certains modèles sont en concurrence (c.-à-d.Active Record et Repository), et sont donc destinés à être utilisés pour des scénarios spécifiques.Bien que CSLA ne corresponde exactement à aucun des modèles décrits dans ce livre, il ressemble le plus à Active Record (même si je pense qu'il serait myope de prétendre une correspondance exacte pour ce modèle).

5.Si vous avez arrêté de l’utiliser ou avez décidé de ne pas l’utiliser, pourquoi ?
Je n'ai pas entièrement recommandé CSLA pour mon dernier projet, car je pense que la portée de l'application est trop large pour les avantages qu'offre CSLA.
Je voudrais pas utiliser CSLA sur un projet Web.Je pense qu'il existe d'autres technologies mieux adaptées à la création d'applications dans cet environnement.

En résumé, même si CSLA est tout sauf un balle en argent, cela convient à certains scénarios.

J'espère que cela t'aides!

Autres conseils

Après avoir lu toutes les réponses, j'ai remarqué que de nombreuses personnes ont des idées fausses sur CSLA.

D'abord, CSLA n'est pas un ORM.Comment puis-je dire cela avec autant de certitude ?Parce que Rockford Lhotka l'a lui-même déclaré à plusieurs reprises dans des interviews sur le .NET Roches et Hanselminutes podcasts.Chercher n'importe lequel épisode où Rocky a été interviewé et il le dira sans équivoque.Je pense que c'est le fait le plus important que les gens doivent comprendre, car presque toutes les idées fausses sur CSLA découlent du fait de croire qu'il s'agit d'un ORM ou de tenter de l'utiliser comme tel.

Comme Brad Leach l'a mentionné dans sa réponse, les objets CSLA modélisent le comportement, même s'il peut être plus exact de dire qu'ils modélisent le comportement des données, puisque les données en font partie intégrante.CSLA n'est pas un ORM car il est totalement indépendant de la façon dont vous communiquez avec votre magasin de données.Toi devrait utilisez une sorte de couche d'accès aux données avec CSLA, peut-être même un ORM.(Je fais.J'utilise maintenant Entity Framework, qui fonctionne à merveille.)

Passons maintenant aux tests unitaires.Je n'ai jamais eu de difficulté à tester unitairement mes objets CSLA, car je ne mets pas mon code d'accès aux données directement dans mes objets métier.Au lieu de cela, j'utilise une variante du modèle de référentiel. Le référentiel est consommé par CSLA, et non l'inverse. En échangeant un faux référentiel pour mes tests unitaires et en utilisant le portail de données local, BOOM! c'est simple.(Une fois qu'Entity Framework autorisera l'utilisation de POCO, ce sera encore plus propre.)

Tout cela vient du fait que CSLA n’est pas un ORM.Il peut consommer un ORM, mais il n’en est pas un.

Acclamations.

MISE À JOUR

J'ai pensé faire quelques commentaires supplémentaires.

Certaines personnes ont dit que CSLA était verbeux par rapport à des choses comme LINQ to SQL, etc.Mais ici, nous comparons des pommes avec des oranges.LINQ to SQL est un ORM.Il offre certaines choses que CSLA n'offre pas, et CSLA offre certaines choses que L2S n'offre pas, comme la validation intégrée et nPersistance à plusieurs niveaux via les différents portails de données distants.En fait, je dirais cette dernière chose, nla persévérance à un niveau supérieur les surpasse tous pour moi.Si je veux utiliser Entity Framework ou LINQ to SQL sur le net, je dois mettre quelque chose comme WCF entre les deux, et cela multiplie énormément le travail et la complexité, au point où je pense que c'est beaucoup plus verbeux que CSLA.(Maintenant, je suis fan de WCF, REST et SOA, mais utilisez-les là où vous en avez vraiment besoin, par exemple lorsque vous souhaitez exposer un service à des tiers.Pour la plupart des applications métier, ce n'est pas vraiment nécessaire et CSLA est un meilleur choix.) En fait, avec la dernière version de CSLA, Rocky fournit un WCFDataPortal, que j'ai utilisé.Cela fonctionne très bien.

je suis fan de SOLIDE, TDD et d'autres principes de développement de logiciels modernes, et utilisez-les autant que possible.Mais je pense que les avantages de CSLA dépassent certaines des objections de ces orthodoxies, et en tout cas, j'ai réussi à faire fonctionner CSLA assez bien (et facilement) avec TDD, donc ce n'est pas un problème.

Oui, je (euh, nous) l'avons largement utilisé pour modéliser notre logique de processus métier qui était principalement constituée de formulaires liés aux données dans une application Windows Forms.L'application était un système commercial.CSLA est conçu pour se trouver à cette couche juste en dessous de l'interface utilisateur.

Si vous pensez à votre application métier complexe et standard, vous pouvez avoir un formulaire avec de nombreux champs, de nombreuses règles pour ces champs (y compris des règles de validation entre champs), vous pouvez appeler une boîte de dialogue modale pour modifier un objet enfant, vous pouvez Je souhaite pouvoir annuler de tels dialogues et revenir à un état antérieur.CSLA soutient cela.

L'inconvénient est qu'il nécessite un peu de courbe d'apprentissage.

L’élément clé à retenir est d’utiliser CSLA pour modéliser la façon dont un utilisateur interagit avec les formulaires de certaines applications.Le moyen le plus efficace pour moi était de concevoir l'interface utilisateur et de comprendre ses flux, son comportement et ses règles de validation avant de créer les objets CSLA.Ne laissez pas vos objets CSLA piloter la conception de l'interface utilisateur.

Nous avons également trouvé très utile de pouvoir utiliser les objets métier CSLA côté serveur pour valider les objets envoyés par les clients.

Nous avions également des mécanismes intégrés pour effectuer une validation de manière asynchrone sur le service Web (c'est-à-direvérifier la fourchette de limite de crédit d'une contrepartie par rapport à un maître).

CSLA applique une forte séparation entre votre interface utilisateur, BusinessLogic et Persistance et nous avons écrit de nombreux tests unitaires contre eux.Ce n'est peut-être pas strictement TDD parce que vous le pilotez à partir de la conception de l'interface utilisateur, cela ne veut pas dire qu'il n'est pas testable.

La seule véritable alternative est de créer votre propre modèle \ objets métier, mais très vite, vous finissez par implémenter les fonctionnalités proposées par CSLA (INotifyPropertyChanged, IDataErrorInfo, PushState, PopState, etc.)

J'ai utilisé CSLA pour un projet et cela a très bien fonctionné et a rendu les choses beaucoup plus simples et plus soignées.

Au lieu de demander à votre équipe d'écrire des objets métier dans son propre style personnel, nous savons qu'il existe une norme commune sur laquelle travailler.

//Andy

J'en ai fait l'expérience il y a plusieurs années.Il s'agit d'une architecture brillante, mais très complexe, difficile à comprendre ou à modifier, et elle résout un problème que la plupart d'entre nous qui développons des applications Web n'avons pas nécessairement.Il a été développé davantage pour les applications basées sur Windows et pour la gestion des annulations à plusieurs niveaux, avec un fort accent sur la logique transactionnelle.Vous entendrez probablement des gens dire que puisque les applications Web sont des requêtes-réponses au niveau de la page, cela est inapproprié, mais avec les applications Web de style AJAX, cet argument ne tient peut-être pas autant d'eau.

Il a un modèle objet très profond, et cela peut prendre un certain temps pour vraiment comprendre votre cerveau.Bien sûr, beaucoup de choses peuvent changer en quelques années.Je serais intéressé d'entendre d'autres avis récents.

Tout bien considéré, ce ne serait pas mon premier choix d’architecture.

Pour défendre le CSLA, même si je suis d'accord avec de nombreux commentaires qui ont été faits, en particulier celui des tests unitaires...

Mon entreprise l'a largement utilisé pour une application de saisie de données Windows Forms, avec un grand succès.

  • Il fournissait des fonctionnalités prêtes à l'emploi que nous n'avions ni le temps ni l'expertise nécessaires pour écrire nous-mêmes.
  • Il a standardisé tous nos objets métier, facilitant la maintenance et réduisant la courbe d'apprentissage de nos nouveaux développeurs.

Dans l’ensemble, je dirais que tous les problèmes que cela a causés ont été plus que compensés par les avantages.

MISE À JOUR:De plus, nous l'utilisons toujours pour notre application Windows Forms, mais des expériences avec son utilisation pour d'autres applications telles que des sites Web ont montré qu'il est peut-être trop encombrant lorsque vous n'avez pas besoin d'une grande partie de ses fonctionnalités et nous étudions maintenant un poids plus léger. options pour ces scénarios.

J'ai rejoint une équipe où CSLA est obligatoire.Nous n'utilisons pas le portail de données distant, ce qui est la seule raison pour laquelle je pourrais accepter l'utilisation de ce framework.Je n'ai jamais adhéré à l'idée de CSLA, alors c'est peut-être pour cela que je n'ai que des problèmes avec cela, désolé.

Quelques problèmes :

Je n'ai pas besoin d'un obstacle entre mon code et le framework .NET, c'est ce que ce framework m'a semblé.J'avais une option limitée d'objets de liste, alors que je devais simplement ignorer les objets de liste riches dans le framework .NET.

C'est totalement ridicule que nous ayons ces listes en lecture seule, puis des listes non en lecture seule.Donc, si je devais ajouter un élément à la liste, je devais recréer la liste entière... tu es sérieux ?

Ensuite, csla veut gérer l'état de mon objet, ce qui est bien mais rien n'est vraiment exposé.Parfois, je souhaite modifier l'état d'un objet manuellement au lieu de le récupérer à nouveau, ce qui semble être ce que csla veut que je fasse.En gros, je finis par créer de nombreuses propriétés pour exposer des options auxquelles csla ne pensait pas que je devrais avoir un accès direct.

Pourquoi ne puis-je pas simplement instancier un objet ?Nous finissons par créer des méthodes statiques qui instancient un objet et le renvoie... vous vous moquez de moi ?

Vérifiez le code source du framework et cela me semble trop lourd sur le code de réflexion.

Raisons d’utiliser csla :

  • le framework .net simple est trop puissant pour vous.
  • vos développeurs ne sont pas expérimentés et ne peuvent pas comprendre le concept de modèles, alors csla mettra à peu près tout le monde sur la même longueur d'onde.

    1. Je n'ai pas besoin d'un barrage routier entre mon code et le framework .NET... Je suis coincé avec ces objets de liste.

Nous avons commencé à utiliser CSLA parce que nous pensions que cela nous aiderait avec notre couche de modèle.C'était en quelque sorte exagéré et la plupart du temps, tout ce que nous utilisons maintenant est la classe SmartDate, simplement parce que nous sommes déjà liés à la bibliothèque.

Nous pensions que l'interface de validation nous aiderait vraiment à appliquer les règles métier, mais elle ne fonctionnait pas bien avec WCF et la sérialisation (nous sommes toujours bloqués sur la version 2.0.3.0, donc les choses ont peut-être changé).

Ne prenez pas CSLA de la liste, mais avant de l'utiliser, recherchez les avantages et assurez-vous qu'ils s'appliquent réellement.Votre équipe sera-t-elle capable de le mettre en œuvre correctement/de manière cohérente ?La danse à distance et sur le portail est-elle nécessaire ?

Je pense qu'au-delà de toute réflexion théorique, il s'agit avant tout d'un code propre/maintenable/extensible/testable suivant des modèles de base éprouvés.

J'ai compté les lignes de code nécessaires dans un domaine spécifique d'un projet converti à partir de CSLA.Entre tous les différents objets CSLA (combinaisons lecture seule + éditable + racine + liste) et leurs processus stockés, cela a pris environ 1 700 lignes, contre une implémentation Linq2SQL + Repository qui prenait 180 lignes.La version Linq2SQL se composait principalement de classes générées que votre équipe n'a pas besoin de lire un livre pour comprendre.Et oui, j'ai utilisé CodeSmith pour générer les parties CSLA, mais je crois maintenant au code DRY avec des bits de responsabilité uniques, et l'implémentation CSLA me ressemble désormais comme le héros d'hier.

Comme alternative, je voudrais suggérer d'examiner Linq2Sql/Entity Framework/NHibernate combiné avec les modèles Repository et UnitOfWork.Jettes un coup d'oeil à http://www.codeplex.com/backgroundmotion

Acclamations!

Notre entreprise a mis en pratique CSLA dans certains de ses projets et certains des projets hérités restent des CSLA.D'autres projets s'en sont éloignés parce que CSLA a violé une règle claire et simple de POO :Principe de responsabilité unique.

Les objets CSLA sont autonomes, par ex.ils récupèrent leurs propres données, ils gèrent leur propre comportement, ils se sauvent.Malheureusement, cela signifiait que votre objet CSLA moyen avait au moins trois responsabilités : représenter le modèle de domaine, contenir les règles métier et contenir la définition de l'accès aux données (pas le DAL, ou la mise en œuvre de l'accès aux données, comme je l'ai dit/sous-entendu précédemment) en même temps. temps.

Nous utilisons largement CSLA.Il y a plusieurs avantages ;Tout d'abord, je pense que chaque développeur de secteur d'activité devrait lire le livre de Rocky Lhotka sur la programmation Business Objects.Personnellement, je l'ai trouvé dans mon top 3 des meilleurs livres de programmation de tous les temps.CSLA est un framework basé sur ce livre et son utilisation donne à votre projet l'accès à des fonctionnalités de très haut niveau telles que l'annulation à n niveaux, les règles de validation et l'architecture d'évolutivité tout en vous fournissant les détails.Remarquez que j'ai dit "fournir" et non "cacher".J'ai trouvé que la meilleure partie de CSLA est qu'elle vous permet de comprendre comment toutes ces choses sont implémentées jusqu'au code source sans vous obliger à les reproduire vous-même.Vous pouvez choisir d'utiliser autant ou peu de fonctionnalités que vous le souhaitez, mais j'ai constaté qu'en restant fidèle aux modèles de conception du framework, cela vous évite vraiment des ennuis.-Byron

Nous utilisons CSLA depuis plus de cinq ans et nous pensons qu'il fonctionne très bien pour créer des applications métier.Couplé à la génération de code, vous pouvez créer des objets métier dans un laps de temps relativement court et concentrer vos efforts sur le viande de la demande.

J'utilise CSLA depuis vb5, alors qu'il s'agissait plus d'une collection de modèles que d'un framework.Avec l’introduction de .NET, CSLA s’est transformé en un framework à part entière, qui s’accompagne d’une lourde courbe d’apprentissage.Cependant, le CSLA aborde de nombreuses choses que tous les développeurs d’affaires ont tendance à écrire eux-mêmes à un moment donné (en fonction de la portée du projet) :logique de validation, logique d'authentification, fonctionnalité d'annulation, logique sale, etc.Toutes ces choses que vous obtenez gratuitement, prêtes à l’emploi, dans un cadre agréable.

Comme d'autres l'ont déclaré, étant un framework, il oblige les développeurs à écrire une logique métier de la même manière.Cela vous oblige également à fournir un niveau d'abstraction pour votre logique métier, de sorte que ne pas utiliser un framework d'interface utilisateur tel que MVC, MVP, MVVM ne devienne pas si important.

En fait, je dirais que la raison pour laquelle tant de ces modèles d'interface utilisateur sont si en vogue aujourd'hui (dans le monde Microsoft) est que les gens font des choses incroyablement mauvaises depuis si longtemps (c'est-à-dire, utiliser des DataGrids dans votre interface utilisateur, saupoudrer votre logique métier partout.risque, risque).Concevez correctement votre niveau intermédiaire (logique métier) dès le départ, vous pouvez réutiliser votre niveau intermédiaire dans N'IMPORTE QUELLE interface utilisateur.Win Form, ASP.NET/MVC, Service WCF, WPF, Silverlight**, Service Windows, ....

Mais à part cela, l’énorme avantage pour moi a été sa capacité intégrée d’évolutivité.Le CSLA utilise un modèle de proxy configurable via votre fichier de configuration.Cela permet à vos objets métier d'effectuer des appels à distance de serveur à serveur, sans avoir à écrire un seul coup de code.Ajouter plus d'utilisateurs à votre système ?Pas de problème, déployez vos objets métier CSLA sur un nouveau serveur d'applications, modifiez l'entrée du fichier de configuration, et BAM !!Besoins d’évolutivité instantanés satisfaits.

Comparez cela à l'utilisation de DTO, au stockage de votre logique métier sur le client (quel que soit le client) et à la nécessité d'écrire chacune de vos propres méthodes CRUD en tant que méthodes de service.OUI !!!Je ne dis pas que c’est une mauvaise approche, mais je ne voudrais pas le faire.Pas quand il existe un cadre pour le faire essentiellement à ma place.

Je vais réitérer ce que d'autres personnes ont dit, à savoir que CSLA n'est PAS un ORM.CSLA vous oblige à fournir des données à vos objets métier.Ils ne se soucient pas de l'endroit où vous obtenez vos données.Vous pouvez utiliser un ORM pour fournir des données à vos objets métier.Vous pouvez également utiliser ADO.NET brut, d'autres services (RESTFUl, SOAP), des feuilles de calcul Excel, je peux continuer ici.

Quant à votre support pour TDD, je n'ai jamais non plus essayé d'utiliser cette approche avec CSLA.J'ai adopté l'approche dans laquelle je modélise mon niveau intermédiaire (ala businessobjects) à l'aide de diagrammes de classes et de séquences, permettant le plus souvent de dicter la conception du cas d'utilisation, de l'écran et/ou du processus.Peut-être un peu old school, mais UML m'a toujours très bien servi dans mes efforts de conception et de développement.J'ai conçu et développé avec succès des applications très volumineuses et évolutives encore utilisées aujourd'hui.Et jusqu'à ce que WCF RIA arrive à maturité, je continuerai à utiliser CSLA.

** avec quelques solutions

Je suis nouveau sur CSLA mais je comprends les concepts et je comprends déjà que ce n'est pas un outil ORM, alors arrêtez de battre ce foutu tambour.Il y a des fonctionnalités de CSLA que j'aime, mais les utiliser donne un peu l'impression qu'il y a un magicien derrière le rideau.Je suppose que si cela ne vous dérange pas de ne pas savoir comment cela fonctionne, vous pouvez utiliser les objets et ils fonctionnent bien.

Il y a une grande courbe d'apprentissage pour les débutants et je pense qu'il serait grandement bénéfique de disposer de 5 à 15 minutes.des vidéos comme celles proposées par Microsoft pour apprendre les bases.Ou que diriez-vous de publier un livre d’accompagnement avec le code au lieu de publier le code et de prendre des mois pour sortir le livre ?Je dis juste M. Lohtka...Nous avons commencé à construire notre matériel avant le livre et j'ai eu du mal tout le temps.Mais comme je l'ai dit, je suis nouveau dans ce domaine.

Nous avons utilisé CSLA.Nous avons adapté nos objets à leur moule puis utilisé 10% de ce que proposait le cadre.Annuler au niveau de l'objet ?Je ne l'ai pas utilisé.Flexibilité à un niveau supérieur ?Je ne l'ai pas utilisé.Nous avons fini par écrire suffisamment de code de règles métier pour que je pensais que la seule chose que nous retirons de CSLA était la complexité.Certains développeurs « longs dans les dents » qui connaissent le framework l'ont utilisé comme marteau parce qu'ils avaient un clou à frapper.L’AAPC était à leur côté et je suppose que de nombreux partisans du cadre voient également les choses de ce point de vue.

Je suppose que nos développeurs chevronnés sont heureux parce que tout cela a du sens pour eux.Je suppose que si votre organisation n'a pas de programmeurs débutants et que vous vous ennuyez en écrivant des objets POCO efficaces et simples avec des modèles bien formés, alors allez-y.Utilisez CSLA.

J'utilise CSLA comme cadre d'objet métier pour un projet de taille moyenne.Le framework a parcouru un long chemin depuis l'époque VB6 et offre une flexibilité extraordinaire et des fonctionnalités « prêtes à l'emploi ».Les objets intelligents mobiles de CSLA facilitent grandement le développement de l'interface utilisateur.Cependant, je suis d’accord avec les autres, ce n’est pas le bon outil pour chaque situation.Il y a certainement des frais généraux impliqués, mais aussi beaucoup de puissance.Personnellement, j'ai hâte d'utiliser CSLA Light avec Silverlight.

Avantages:

  • Indépendant de la technologie des données1
  • Grande base d'installation et c'est GRATUIT !!
  • Cadre stable et logique
  • Le code d'accès aux données peut se trouver dans vos objets ou dans un assembly séparé
  • Validation et autorisation des propriétés et des objets

Les inconvénients

  • Le code peut être difficile à maintenir2
  • Il faudra probablement un générateur de code pour l'utiliser efficacement
  • Courbe d'apprentissage.La structure des objets CSLA est facile à comprendre, mais les mises en garde peuvent créer des maux de tête.


Je ne suis pas sûr de la conception pilotée par les tests.Je ne fais pas de tests unitaires ni de conception pilotée par les tests (honte à moi), donc je ne sais pas si les tests unitaires sont différents de TDD, mais je sais que la version la plus récente du framework est livrée avec des tests unitaires.


1 Heureusement, car les technologies d’accès aux données ne restent jamais les mêmes longtemps.
2 Cela s'est amélioré avec les versions récentes du framework.

De nombreuses personnes recommandent d'utiliser la génération de code avec CSLA.Je vous recommande de consulter notre ensemble de modèles pris en charge, car ils augmenteront considérablement votre retour sur investissement.

Merci -Blake Niemyjski (auteur du Modèles CSLA CodeSmith)

Je l'ai utilisé pour un projet il y a quelques années.Mais une fois le projet terminé, je ne pouvais dire à personne ce que CSLA avait fait pour moi.Bien sûr, j'ai hérité de ses cours.Mais j’ai pu supprimer cet héritage de presque toutes les classes sans aucune restructuration.Nous n’avions aucune utilité pour les trucs N-Tier.L'annulation au niveau N était si lente que nous ne pouvions pas l'utiliser.Donc je suppose qu'à la fin, cela nous a seulement aidé à modéliser nos cours.

Cela dit, d'autres équipes ont commencé à l'utiliser (après une horrible tentative d'une équipe de créer son propre framework).Il doit donc y avoir quelque chose de valable là-dedans, car ils sont tous plus intelligents que moi !

Je suis un gars PHP.Lorsque nous avons commencé à créer des applications à relativement grande échelle avec PHP, j'ai commencé à faire des recherches sur de nombreux frameworks d'applications et ORM essentiellement dans le monde PHP, puis dans Java et .NET.La raison pour laquelle j'ai également examiné les frameworks Java et .NET n'était pas d'utiliser aveuglément un framework PHP, mais d'essayer d'abord de comprendre ce qui se passe réellement et quels types d'architectures au niveau de l'entreprise existent.

Parce que je n'ai pas utilisé CSLA dans une application réelle, je ne peux pas commenter ses avantages et ses inconvénients, mais ce que je peux dire, c'est que Lhotka est l'un des rares penseurs - je ne dis pas seulement un expert - dans le domaine de l'architecture logicielle.Bien que le nom Domain Driven Design soit inventé par Eric Evans (d'ailleurs son livre est également excellent et je conseille humblement de le lire), Lhotka appliquait la conception pilotée par domaine depuis des années.Cela dit, quoi que vous pensiez de son cadre, bénéficiez de ses idées profondes en la matière.

Vous pouvez retrouver ses conférences sur dotnetrocks.com/archives.aspx et des vidéos sur dnrtv.com/archives.aspx (recherchez Lhotka).

@Byron Quels sont les deux autres livres que vous avez aimés?

John,

Nous avons des équipes qui travaillent dans CSLA de 2 à 3.5 et avons trouvé que c'était un excellent moyen de fournir un cadre cohérent afin que tous les développeurs « le fassent de la même manière ».C'est formidable que la plupart du code de faible valeur soit généré et nous savons que lorsque nous exécutons des tests unitaires, ils fonctionnent immédiatement pour tous les éléments CRUD.Nous constatons que notre TDD intervient vraiment avec la refactorisation que nous effectuons pour concevoir, et CSLA ne nous empêche pas de faire tout cela.

Chris

J'ai essayé pour la dernière fois d'utiliser CSLA à l'époque de l'âge de pierre de VB6.Rétrospectivement, cela aurait été plus efficace si j'avais utilisé la génération de code.Si vous ne disposez pas d'outils de génération de code efficaces ni d'une stratégie pour les intégrer à votre flux de travail, vous devez éviter les frameworks comme CSLA, sinon les fonctionnalités que vous obtenez de CSLA ne compenseront pas le temps que vous passez à écrire n lignes. de code par table, n lignes de code par colonne, etc.

J'ai utilisé CSLA.NET dans quelques projets maintenant, il a eu plus de succès dans une application Windows Forms qui possède de riches compatibilités de liaison de données (que les applications asp.net n'ont pas).

Son principal problème est la prise en charge de TDD, comme les gens l'ont souligné, en raison du comportement de type boîte noire pour les fonctions Dataportal_XYZ et de son incapacité à nous permettre de nous moquer des objets de données.Des efforts ont été déployés pour contourner ce problème avec ce étant la meilleure approche

Je voulais l'utiliser, mais mon développeur principal de l'époque avait l'idée que trop de « magie » était impliquée...

CSLA est le meilleur cadre d’application qui existe.Rocky LHotka est un gars très mais très intelligent.Il écrit l'histoire du développement logiciel comme Martin Fowler, David S Platt, mais mes écrivains préférés sont Rod Stephens, Jeff Levinson de Mathew McDonald, Thearon Willis et Louis Davidson alias Dr SQL.:-) Avantages:Tous les modèles de conception sont appliqués.Les inconvénients:Difficile à apprendre et peu d'échantillons.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top