Qualcuno ha qualche esperienza nel mondo reale di CSLA?

https://stackoverflow.com/questions/15241

08-06-2019
|

Domanda

L'applicazione web principale della mia azienda richiede ardentemente un insieme elegante di librerie che la rendano in qualche modo manutenibile e scalabile, e uno dei miei colleghi ha suggerito CSLA.Quindi ho comprato il libro ma come:

i programmatori non leggono più libri

Volevo valutare l'opinione della comunità SOFlow al riguardo.

Quindi ecco le mie domande:

In che modo le persone utilizzano CSLA?
Quali sono i pro e i contro?
CSLA davvero non si adatta a TDD?
Quali sono le mie alternative?
Se hai smesso di usarlo o hai deciso di non farlo, perché?

Soluzione

Prima di rispondere specificamente alla tua domanda, vorrei esprimere alcune riflessioni.CSLA è adatto al tuo progetto?Dipende.Personalmente considererei CSLA per le applicazioni basate su desktop che non attribuiscono ai test unitari una priorità elevata.CSLA è ottimo se desideri scalare facilmente un'applicazione a più livelli.CSLA tende ad essere criticato perché non consente il puro test unitario.Questo è vero, tuttavia, come qualsiasi cosa nella tecnologia, credo che esista Nessun vero modo.Il test unitario potrebbe non essere qualcosa che stai intraprendendo per un progetto specifico.Ciò che funziona per un team e un progetto potrebbe non funzionare per un altro team o un altro progetto.

Ci sono anche molte idee sbagliate riguardo al CSLA.Non è un ORM.non è un concorrente di NHibernate (in effetti l'utilizzo di CLSA Business Objects e NHibernate come accesso ai dati si adatta molto bene insieme).Formalizza il concetto di a Oggetto mobile.

1.Quante persone utilizzano CSLA?
Basato sul Forum CSLA, direi che ci sono parecchi progetti basati su CSLA là fuori.Onestamente, però, non ho idea di quante persone lo stiano effettivamente utilizzando.L'ho usato in passato su due progetti.

2.Quali sono i pro e i contro?
Anche se è difficile riassumerli in un breve elenco, ecco alcuni dei pro/contro che mi vengono in mente.
Professionisti:

È facile far crescere i nuovi sviluppatori alla velocità.Il libro e l'esempio CSLA Le app sono ottime risorse per aggiornarsi.
Il framework di validazione è veramente di prim'ordine ed è stato "preso in prestito" per moltissimi altri progetti e tecnologie non CSLA.
Annullamento a livello n all'interno degli oggetti aziendali
Modifica della riga di configurazione per la scalabilità a più livelli (Nota:nemmeno un è necessaria la ricompilazione)
Le tecnologie chiave sono astratte dal codice "reale".Quando WCF è stato introdotto, ha avuto un impatto minimo Codice CSLA.
È possibile condividere i tuoi oggetti aziendali tra finestre e progetti web.
CSLA promuove la normalizzazione del comportamento piuttosto che la normalizzazione di dati (lasciando il database per la normalizzazione dei dati).

Contro:

Difficoltà nel test unitario
Mancanza di separazione degli interessi (generalmente i tuoi oggetti aziendali contengono al loro interno un codice di accesso ai dati).
Poiché CSLA promuove la normalizzazione del comportamento, piuttosto che la normalizzazione di dati, e ciò può comportare la creazione di oggetti business con nomi simili, ma con scopi diversi.Ciò può causare confusione e la sensazione di non riutilizzare gli oggetti in modo appropriato.Detto questo, una volta compiuto il salto fisiologico, è più che sensato: sembra inappropriato strutturare gli oggetti alla “vecchia” maniera.
Non è "di moda" creare applicazioni in questo modo.Potresti avere difficoltà a trovare sviluppatori appassionati della tecnologia.

3.Dopo aver letto questo, CSLA non si adatta davvero a TDD?
Non ho trovato un modo efficace per eseguire TDD con CSLA.Detto questo, sono sicuro che ci siano molte persone più intelligenti là fuori di me che potrebbero averlo provato con maggiore successo.

4.Quali sono le mie alternative?
La progettazione basata sui domini sta ottenendo grande successo in questo momento (e giustamente: è fantastica per alcune applicazioni).Esistono anche una serie di modelli interessanti che si sviluppano dall'introduzione di LINQ (e LINQ to SQL, Entity Framework, ecc.).Libro di Fowler PoEAA, descrive in dettaglio molti modelli che potrebbero essere adatti alla tua applicazione.Tieni presente che alcuni modelli sono in competizione (ad es.Active Record e Repository) e quindi sono pensati per essere utilizzati per scenari specifici.Sebbene CSLA non corrisponda esattamente a nessuno dei modelli descritti in quel libro, assomiglia molto ad Active Record (anche se ritengo che sia miope affermare una corrispondenza esatta per questo modello).

5.Se hai smesso di usarlo o hai deciso di non farlo, perché?
Non ho consigliato completamente CSLA per il mio ultimo progetto perché ritengo che l'ambito dell'applicazione sia troppo ampio per i vantaggi offerti da CSLA.
Vorrei non utilizzare CSLA su un progetto web.Ritengo che esistano altre tecnologie più adatte alla creazione di applicazioni in quell'ambiente.

In sintesi, mentre CSLA è tutt’altro che a Proiettile d'argento, è appropriato per alcuni scenari.

Spero che questo ti aiuti!

Altri suggerimenti

Dopo aver letto tutte le risposte, ho notato che molte persone hanno idee sbagliate su CSLA.

Primo, CSLA non è un ORM.Come posso dirlo in modo così definitivo?Perché lo stesso Rockford Lhotka lo ha affermato più volte nelle interviste su .NET Rocce E Hanselminuti podcast.Cercare Qualunque episodio in cui Rocky è stato intervistato e lo dirà senza mezzi termini.Penso che questo sia il fatto più importante da comprendere per le persone, perché quasi tutte le idee sbagliate sul CSLA derivano dal credere che sia un ORM o dal tentativo di usarlo come tale.

Come ha accennato Brad Leach nella sua risposta, CSLA si oppone al comportamento del modello, anche se potrebbe essere più accurato dire che modellano il comportamento dei dati, poiché i dati sono parte integrante di essi.CSLA non è un ORM perché è completamente agnostico riguardo al modo in cui comunichi al tuo archivio dati.Voi Dovrebbe utilizzare una sorta di livello di accesso ai dati con CSLA, forse anche un ORM.(Io faccio.Ora utilizzo Entity Framework, che funziona magnificamente.)

Ora passiamo ai test unitari.Non ho mai avuto alcuna difficoltà a testare i miei oggetti CSLA, perché non inserisco il codice di accesso ai dati direttamente nei miei oggetti business.Invece, utilizzo qualche variazione del modello di repository. Il repository viene utilizzato da CSLA e non viceversa. Sostituendo un repository falso per i miei test unitari e utilizzando il portale dati locale, BOOM! è semplice.(Una volta che Entity Framework consentirà l'uso di POCO, questo sarà ancora più pulito.)

Tutto ciò deriva dalla consapevolezza che CSLA non è un ORM.Potrebbe consumare un ORM, ma di per sé non lo è.

Saluti.

AGGIORNAMENTO

Ho pensato di fare qualche altro commento.

Alcune persone hanno affermato che CSLA è dettagliato rispetto a cose come LINQ to SQL e così via.Ma qui stiamo confrontando le mele con le arance.LINQ to SQL è un ORM.Offre alcune cose che CSLA non offre e CSLA offre alcune cose che L2S non offre, come la convalida integrata e Npersistenza a livelli attraverso i vari portali dati remoti.In effetti, direi l'ultima cosa, Npersistenza di livello superiore, per me li supera tutti.Se voglio usare Entity Framework o LINQ to SQL in rete, devo mettere qualcosa come WCF in mezzo, e questo moltiplica enormemente il lavoro e la complessità, al punto che penso che sia tanto più dettagliato di CSLA.(Ora, sono un fan di WCF, REST e SOA, ma usalo dove ne hai veramente bisogno, ad esempio quando vuoi esporre un servizio a terze parti.Per la maggior parte delle app line-of-business non è realmente necessario e CSLA è una scelta migliore). Infatti, con l'ultima versione di CSLA, Rocky fornisce un WCFDataPortal, che ho usato.Funziona alla grande.

Sono un fan di SOLIDO, TDD e altri principi moderni di sviluppo software e usali laddove possibile.Ma penso che i vantaggi di CSLA superino alcune delle obiezioni di quelle ortodossie, e in ogni caso sono riuscito a far funzionare CSLA abbastanza bene (e facilmente) con TDD, quindi non è un problema.

Sì, l'ho (ehm, noi) utilizzato ampiamente per modellare la logica del nostro processo aziendale che era principalmente moduli con associazione a dati in un'applicazione Windows Form.L'applicazione era un sistema commerciale.CSLA è progettato per trovarsi a quel livello appena sotto l'interfaccia utente.

Se pensi alla tua complessa applicazione line-of-business standard, potresti avere un modulo con molti campi, molte regole per quei campi (incluse le regole di convalida tra campi), potresti invocare una finestra di dialogo modale per modificare alcuni oggetti secondari, potresti desidera essere in grado di annullare tali finestre di dialogo e ripristinare uno stato precedente.CSLA lo sostiene.

I suoi svantaggi sono che ha un po' di curva di apprendimento.

La cosa fondamentale da ricordare è utilizzare CSLA per modellare come a utente interagisce con i moduli su alcune applicazioni.Il modo più efficiente per me è stato progettare l'interfaccia utente e comprenderne i flussi, il comportamento e le regole di convalida prima di creare gli oggetti CSLA.Non lasciare che gli oggetti CSLA guidino la progettazione dell'interfaccia utente.

Abbiamo anche trovato molto utile poter utilizzare gli oggetti business CSLA lato server per convalidare gli oggetti inviati dai client.

Avevamo anche meccanismi integrati per eseguire la convalida in modo asincrono rispetto al servizio web (ad es.verifica dell'intervallo del limite di credito di una controparte rispetto a un master).

CSLA impone una forte separazione tra l'interfaccia utente, BusinessLogic e Persistenza e abbiamo scritto un sacco di test unitari contro di essi.Potrebbe non essere strettamente TDD perché lo stai guidando dalla progettazione dell'interfaccia utente, ciò non significa che non sia testabile.

L'unica vera alternativa è creare il proprio modello/oggetto business, ma ben presto si finisce per implementare le funzionalità che CSLA offre immediatamente (INotifyPropertyChanged, IDataErrorInfo, PushState, PopState ecc.)

Ho utilizzato CSLA per un progetto e ha funzionato benissimo e ha reso le cose molto più semplici e ordinate.

Invece di lasciare che il tuo team scriva oggetti di business secondo il proprio stile personale e diverso, sappiamo di avere uno standard comune contro cui lavorare.

//andy

Ne ho avuto esperienza diversi anni fa.È un'architettura brillante, ma molto complessa, difficile da capire o modificare, e risolve un problema che la maggior parte di noi che sviluppa applicazioni basate sul web non necessariamente ha.È stato sviluppato maggiormente per applicazioni basate su Windows e per la gestione di annullamenti multilivello, con una forte enfasi sulla logica transazionale.Probabilmente sentirai persone dire che, poiché le applicazioni web sono richieste-risposte a livello di pagina, è inappropriato, ma con le app web in stile AJAX forse questo argomento non regge così tanto.

Ha un modello di oggetti molto profondo e può volerci un po' di tempo per capirlo davvero.Naturalmente in pochi anni molte cose possono cambiare.Mi interesserebbe sentire altri pareri recenti.

Tutto considerato, non sarebbe la mia prima scelta di architettura.

In difesa del CSLA, anche se sono d'accordo con molti dei commenti che sono stati fatti, in particolare quello relativo ai test unitari...

La mia azienda lo ha utilizzato ampiamente per un'applicazione di immissione dati Windows Form, con un alto grado di successo.

Forniva funzionalità pronte all'uso che non avevamo il tempo o l'esperienza per scrivere noi stessi.
Ha standardizzato tutti i nostri oggetti aziendali semplificando la manutenzione e riducendo la curva di apprendimento per i nostri nuovi sviluppatori.

Nel complesso direi che tutti i problemi causati sono stati più che superati dai benefici.

AGGIORNAMENTO:Oltre a ciò, lo stiamo ancora utilizzando per la nostra app Windows Form, ma gli esperimenti con il suo utilizzo per altre applicazioni come i siti Web hanno dimostrato che forse è troppo ingombrante quando non sono necessarie molte delle sue funzionalità e ora stiamo studiando un peso più leggero opzioni per questi scenari.

Sono entrato a far parte di un team in cui CSLA è obbligatorio.Non utilizziamo il portale dati remoto che è l'unico motivo per cui potrei accettare l'utilizzo di questo framework.Non ho mai creduto all'idea di CSLA, quindi forse è per questo che non ho altro che problemi, mi spiace.

Un paio di problemi:

Non ho bisogno di un ostacolo tra il mio codice e il framework .NET, che è ciò che mi è sembrato questo framework.Avevo un'opzione limitata di oggetti elenco, mentre dovevo semplicemente ignorare gli oggetti elenco ricchi nel framework .NET.

È totalmente ridicolo che avessimo questi elenchi di sola lettura e poi elenchi non di sola lettura.Quindi se dovessi aggiungere un elemento all'elenco dovrei ricreare l'intero elenco... dici sul serio?

Quindi csla vuole gestire lo stato del mio oggetto, il che va bene ma nulla è realmente esposto.A volte voglio modificare manualmente lo stato di un oggetto invece di recuperarlo di nuovo, il che sembra quello che csla vuole che io faccia.Fondamentalmente finisco per creare molte proprietà per esporre opzioni a cui csla non pensava di dover avere accesso diretto.

Perché non posso semplicemente istanziare un oggetto?Alla fine creiamo metodi statici che istanziano un oggetto e lo restituiscono... mi stai prendendo in giro?

Controlla il codice sorgente del framework e mi sembra troppo pesante sul codice di riflessione.

Motivi per utilizzare csla:

il framework .net diretto è troppo potente per te.
i tuoi sviluppatori non sono esperti e non riescono a cogliere il concetto di pattern, quindi csla avrà praticamente tutti sulla stessa pagina.
1. Non ho bisogno di un ostacolo tra il mio codice e il framework .NET... sono bloccato con questi oggetti elenco.

Abbiamo iniziato a utilizzare CSLA perché pensavamo che sarebbe stato d'aiuto con il nostro livello del modello.Era un po' eccessivo e per lo più tutto ciò che usiamo ora è la classe SmartDate, solo perché siamo già collegati alla libreria.

Pensavamo che l'interfaccia di convalida ci avrebbe davvero aiutato a far rispettare le regole aziendali, ma non ha funzionato bene con WCF e serializzazione (siamo ancora bloccati sulla versione 2.0.3.0, quindi le cose potrebbero essere cambiate).

Non togliere CSLA dall'elenco, ma prima di utilizzarlo, ricerca i vantaggi e assicurati che si applichino realmente.Il tuo team sarà in grado di implementarlo correttamente/coerentemente?Sono necessari il remoting e la danza del portale?

Penso che al di là di ogni riflessione teorica, si tratti di codice pulito/manutenibile/estensibile/testabile che segue modelli di base comprovati.

Ho contato le righe di codice necessarie in un dominio specifico di un progetto convertito da CSLA.Tra tutti i diversi oggetti CSLA (combinazioni di sola lettura+modificabile+root+elenco) e le relative procedure memorizzate ci sono volute circa 1700 righe, rispetto a un'implementazione Linq2SQL + Repository che richiedeva 180 righe.La versione Linq2SQL consisteva principalmente di classi generate che il tuo team non ha bisogno di consultare libri per comprendere.E sì, ho usato CodeSmith per generare le parti CSLA, ma ora credo nel codice DRY con singoli bit di responsabilità e l'implementazione CSLA ora mi sembra l'eroe di ieri.

In alternativa, vorrei suggerire di esaminare Linq2Sql/Entity Framework/NHibernate combinato con i pattern Repository e UnitOfWork.Dai un'occhiata a http://www.codeplex.com/ backgroundmotion

Saluti!

La nostra azienda ha praticato CSLA in alcuni dei suoi progetti e alcuni dei progetti legacy rimangono CSLA.Altri progetti se ne sono allontanati perché CSLA ha violato una chiara e semplice regola OOP:Principio di responsabilità unica.

Gli oggetti CSLA sono autosufficienti, ad es.recuperano i propri dati, gestiscono il proprio comportamento, si salvano.Sfortunatamente questo significa che l'oggetto CSLA medio ha almeno tre responsabilità: rappresentare il modello di dominio, contenere le regole aziendali e contenere la definizione di accesso ai dati (non il DAL o l'implementazione dell'accesso ai dati, come ho affermato/implicito in precedenza), tutto allo stesso tempo tempo.

Utilizziamo ampiamente CSLA.Ci sono diversi vantaggi;in primo luogo, credo che ogni sviluppatore di settori aziendali dovrebbe leggere il libro di Rocky Lhotka sulla programmazione di Business Objects.Personalmente l'ho trovato tra i miei 3 migliori libri di programmazione di sempre.CSLA è un framework basato su questo libro e il suo utilizzo fornisce al tuo progetto l'accesso a funzionalità di altissimo livello come l'annullamento a livello n, le regole di convalida e l'architettura di scalabilità fornendoti allo stesso tempo i dettagli.Notate che ho detto "fornire" e non "nascondere".Ho scoperto che la parte migliore di CSLA è che ti fa capire come tutte queste cose sono implementate fino al codice sorgente senza costringerti a riprodurle tu stesso.Puoi scegliere di utilizzare tutte le funzionalità di cui hai bisogno o poche, ma ho scoperto che rimanendo fedele ai modelli di progettazione del framework, ti tiene davvero fuori dai guai.--Byron

Utilizziamo CSLA ormai da oltre cinque anni e riteniamo che funzioni benissimo per la creazione di applicazioni aziendali.Insieme alla generazione del codice puoi creare oggetti di business in un tempo relativamente breve e concentrare i tuoi sforzi su carne dell'applicazione.

Utilizzo CSLA da vb5, quando era più una raccolta di pattern che un framework.Con l'introduzione di.NET, CSLA si è trasformato in un framework completo, dotato di una forte curva di apprendimento.Tuttavia, il CSLA affronta molte cose che tutti gli sviluppatori aziendali tendono a scrivere prima o poi (a seconda dell'ambito del progetto):logica di convalida, logica di autenticazione, funzionalità di annullamento, logica sporca, ecc.Tutte queste cose le ottieni gratuitamente e pronte all'uso in un unico bel framework.

Come altri hanno affermato, essendo un framework, costringe gli sviluppatori a scrivere la logica aziendale in modo simile.Ti obbliga inoltre a fornire un livello di astrazione per la tua logica aziendale, in modo che non utilizzare un framework dell'interfaccia utente come MVC, MVP, MVVM non diventi così importante.

In effetti, direi che il motivo per cui così tanti di questi modelli di interfaccia utente sono così pubblicizzati oggi (nel mondo Microsoft) è che le persone hanno fatto cose incredibilmente sbagliate per così tanto tempo (ad esempio, utilizzando DataGrid nell'interfaccia utente, spargendo la tua logica aziendale ovunque.tisk tisk).Progetta correttamente il tuo livello intermedio (logica aziendale) fin dall'inizio, puoi riutilizzarlo in QUALSIASI interfaccia utente.Win Form, ASP.NET/MVC, Servizio WCF, WPF, Silverlight**, Servizio Windows, ....

Ma a parte questi, l'enorme vantaggio per me è stata la sua capacità intrinseca di scalare.Il CSLA utilizza un modello proxy configurabile tramite il file di configurazione.Ciò consente ai tuoi oggetti business di effettuare chiamate remote da server a server, senza dover scrivere una sola riga di codice.Aggiungere più utenti al tuo sistema?Nessun problema, distribuisci i tuoi oggetti business CSLA su un nuovo server applicativo, apporta una modifica alla voce del file di configurazione e BAM!!Esigenze di scalabilità istantanea soddisfatte.

Confrontalo con l'utilizzo di DTO, la memorizzazione della logica aziendale sul client (qualunque sia il client) e la necessità di scrivere ciascuno dei propri metodi CRUD come metodi di servizio.OVVIO!!!Non sto dicendo che questo sia un cattivo approccio, ma non vorrei farlo.Non quando esiste una struttura là fuori che essenzialmente lo fa per me.

Ribadirò ciò che hanno detto altri in quanto CSLA NON è un ORM.CSLA ti obbliga a fornire dati ai tuoi oggetti aziendali.A loro non importa dove prendi i tuoi dati.È possibile utilizzare un ORM per fornire dati ai propri oggetti aziendali.Puoi anche utilizzare ADO.NET non elaborato, altri servizi (RESTFUl, SOAP), fogli di calcolo Excel, posso continuare qui.

Per quanto riguarda il tuo supporto per TDD, non ho mai provato a utilizzare questo approccio nemmeno con CSLA.Ho adottato l'approccio in cui modello il mio livello intermedio (ala business object) utilizzando diagrammi di classi e sequenze, il più delle volte consentendo al caso d'uso, allo schermo e/o alla progettazione del processo di dettare.Forse un po' vecchia scuola, ma UML mi è sempre stato molto utile nei miei sforzi di progettazione e sviluppo.Ho progettato e sviluppato con successo applicazioni molto grandi e scalabili utilizzate ancora oggi.E finché WCF RIA non maturerà, continuerò a utilizzare CSLA..

** con alcune soluzioni alternative

Sono nuovo in CSLA ma capisco i concetti e capisco già che non è uno strumento ORM, quindi smettila di battere quel dannato tamburo, gente.Ci sono funzionalità di CSLA che mi piacciono, ma usarle sembra un po' come se ci fosse un mago dietro le quinte.Immagino che se non ti dispiace non sapere come funziona, puoi usare gli oggetti e funzionano bene.

C'è un'ampia curva di apprendimento per i principianti e penso che trarrebbe grande beneficio avere 5-15 minuti.video come Microsoft ha per apprendere i fondamenti.Oppure che ne dici di pubblicare un libro associato con il codice invece di rilasciare il codice e impiegare mesi per pubblicare il libro?Dico solo signor Lohtka...Abbiamo iniziato a costruire le nostre cose prima del libro e ho lottato per tutto il tempo.Ma come ho detto, sono nuovo.

Abbiamo usato CSLA.Abbiamo adattato i nostri oggetti al loro stampo, quindi abbiamo utilizzato il 10% di ciò che offriva la struttura.Annullare a livello di oggetto?Non l'ho usato.Flessibilità del livello?Non l'ho usato.Alla fine abbiamo scritto abbastanza codice di regole aziendali da farmi pensare che l'unica cosa che avremmo ottenuto da CSLA fosse la complessità.Alcuni sviluppatori "da molto tempo" che conoscono il framework lo hanno usato come martello perché avevano un chiodo che doveva essere colpito.CSLA era nella loro cintura e immagino che molti sostenitori del quadro vedano le cose anche da quella prospettiva.

Immagino che i nostri sviluppatori esperti siano felici perché tutto ha senso per loro.Immagino che se la vostra organizzazione non ha programmatori alle prime armi e voi ragazzi vi annoiate scrivendo oggetti POCO semplici ed efficienti con pattern ben formati, allora fatelo.Usa CSLA.

Sto utilizzando CSLA come framework di oggetti business per un progetto di medie dimensioni.Il framework ha fatto molta strada dai tempi di VB6 e offre una straordinaria quantità di flessibilità e funzionalità "pronte all'uso".Gli oggetti intelligenti mobili di CSLA rendono lo sviluppo dell'interfaccia utente molto più semplice.Tuttavia, sono d'accordo con gli altri che non è lo strumento giusto per ogni situazione.C'è sicuramente un po' di sovraccarico in gioco, ma anche molta potenza.Personalmente non vedo l'ora di utilizzare CSLA Light con Silverlight.

Professionisti:

Agnostico dalla tecnologia dei dati¹
Ampia base di installazione ed è GRATUITO!!
Quadro stabile e logico
Il codice di accesso ai dati può trovarsi negli oggetti o in un assembly separato
Convalida e autorizzazione di proprietà e oggetti

Contro

Il codice può essere molto da mantenere²
Probabilmente è necessario un generatore di codice per utilizzarlo in modo efficace
Curva di apprendimento.La struttura degli oggetti CSLA è facile da comprendere, ma gli avvertimenti possono creare grattacapi.

Non sono sicuro della progettazione basata sui test.Non eseguo test unitari o progettazione basata su test (vergognami), quindi non so se i test unitari sono diversi da TDD, ma so che la versione più recente del framework viene fornita con test unitari.

¹ È un bene perché le tecnologie di accesso ai dati non rimangono mai le stesse a lungo.
² La situazione è migliorata con le versioni recenti del framework.

Molte persone consigliano di utilizzare Code Generation con CSLA.Ti consiglio di dare un'occhiata al nostro set di modelli supportati poiché aumenteranno enormemente il tuo ROI.

Grazie -Blake Niemyjski (Autore del Modelli CSLA di CodeSmith)

L'ho usato per un progetto un paio di anni fa.Ma una volta terminato il progetto, non potevo dire a nessuno cosa CSLA ha fatto per me.Certo, ho ereditato dalle sue classi.Ma sono riuscito a rimuovere quell’eredità da quasi tutte le classi senza alcuna ristrutturazione.Non avevamo alcuna utilità per le cose di livello N.L'annullamento a livello n era così lento che non potevamo usarlo.Quindi immagino che alla fine ci abbia solo aiutato a modellare le nostre lezioni.

Detto questo, altri team hanno iniziato a usarlo (dopo un orribile tentativo da parte di un team di creare il proprio framework).Quindi deve esserci qualcosa di utile lì dentro, perché sono tutti più intelligenti di me!

Sono un ragazzo PHP.Quando abbiamo iniziato a creare applicazioni su larga scala con PHP, ho iniziato a ricercare su molti framework applicativi e ORM essenzialmente nel mondo PHP, poi in Java e .NET.Il motivo per cui ho esaminato anche i framework Java e .NET non è stato quello di utilizzare ciecamente qualsiasi framework PHP, ma prima cercare di capire cosa sta realmente accadendo e che tipo di architetture di livello aziendale esistono.

Poiché non ho utilizzato CSLA in un'applicazione del mondo reale, non posso commentare i suoi pro e contro, ma quello che posso dire è che Lhotka è uno dei rari pensatori, non dico solo esperto, nel campo dell'architettura software.Sebbene il nome Domain Driven Design sia stato coniato da Eric Evans - tra l'altro anche il suo libro è fantastico e consiglio umilmente di leggerlo - Lhotka ha applicato la progettazione guidata dal dominio per anni.Detto questo, qualunque cosa tu pensi della sua struttura, trai vantaggio dalle sue idee profonde sul campo.

Puoi trovare i suoi discorsi su dotnetrocks.com/archives.aspx e i video da dnrtv.com/archives.aspx (cerca Lhotka).

@Byron Quali sono gli altri due libri che ti sono piaciuti?

John,

Abbiamo team che lavorano in CSLA dal 2 al 3.5 e abbiamo trovato un ottimo modo per fornire un framework coerente in modo che tutti gli sviluppatori "lo facciano allo stesso modo".È fantastico che la maggior parte del codice di basso valore venga generato e sappiamo che quando eseguiamo unit test funzionano immediatamente per tutto il materiale CRUD.Troviamo che il nostro TDD intervenga davvero con il refactoring che facciamo per progettare e CSLA non ci impedisce di fare nulla di tutto ciò.

Chris

L'ultima volta che ho provato a utilizzare CSLA ai tempi dell'età della pietra di VB6.In retrospettiva, sarebbe stato più efficace se avessi utilizzato la generazione del codice.Se non disponi di strumenti efficaci per la generazione di codice e di una strategia per adattarli al tuo flusso di lavoro, dovresti evitare framework come CSLA, altrimenti le funzionalità che ottieni da CSLA non compenseranno la quantità di tempo che dedichi a scrivere n righe di codice per tabella, n righe di codice per colonna, ecc.

Ho utilizzato CSLA.NET in alcuni progetti ora, ha avuto più successo in un'applicazione Windows Form che ha ricche compatibilità di associazione dati (che le applicazioni asp.net non hanno).

Il problema principale è il supporto TDD come le persone hanno sottolineato, questo è dovuto al comportamento simile a una scatola nera per le funzioni Dataportal_XYZ e all'incapacità di permetterci di deridere gli oggetti dati.Sono stati fatti sforzi per risolvere questo problema Questo essendo l'approccio migliore

Volevo usarlo, ma il mio allora sviluppatore capo aveva l'idea che ci fosse troppa "magia" coinvolta...

CSLA è il miglior framework applicativo esistente.Rocky LHotka è un ragazzo molto ma molto intelligente.Sta scrivendo la storia dello sviluppo del software come Martin Fowler, David S Platt, ma i miei scrittori preferiti sono Rod Stephens, Mathew mcDonalds, Jeff Levinson thearon willis e Louis Davidson alias dr sql.:-) Pro:Vengono applicati tutti i modelli di progettazione.Contro:Difficile da imparare e pochi campioni.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow