Alguém tem alguma experiência real de CSLA?

https://stackoverflow.com/questions/15241

08-06-2019
|

Pergunta

O principal aplicativo da web da minha empresa clama por um conjunto bacana de bibliotecas para torná-lo de alguma forma sustentável e escalonável, e um de meus colegas sugeriu o CSLA.Então eu comprei o livro, mas como:

programadores não leem mais livros

Eu queria avaliar a opinião da comunidade SOFlow sobre isso.

Então, aqui estão as minhas questões:

Como as pessoas podem usar o CSLA?
Quais são os prós e contras?
O CSLA realmente não se enquadra no TDD?
Quais são minhas alternativas?
Se você parou de usá-lo ou decidiu não usá-lo, por quê?

Solução

Antes de responder especificamente à sua pergunta, gostaria de fazer algumas reflexões.O CSLA é adequado para o seu projeto?Depende.Pessoalmente, eu consideraria o CSLA para aplicativos baseados em desktop que não valorizam os testes unitários como uma alta prioridade.CSLA é ótimo se você deseja escalar facilmente para um aplicativo de n camadas.O CSLA tende a ser criticado porque não permite testes unitários puros.Isto é verdade, no entanto, como qualquer coisa em tecnologia, acredito que há Não existe um caminho verdadeiro.O teste unitário pode não ser algo que você esteja realizando para um projeto específico.O que funciona para uma equipe e um projeto pode não funcionar para outra equipe ou outro projeto.

Existem também muitos equívocos em relação ao CSLA.Não é um ORM.não é um concorrente do NHibernate (na verdade, usando CLSA Business Objects e NHibernate, pois o acesso a dados se encaixa muito bem).Ele formaliza o conceito de Objeto móvel.

1.Quantas pessoas estão usando CSLA?
Com base no Fóruns CSLA, eu diria que existem vários projetos baseados em CSLA por aí.Honestamente, não tenho ideia de quantas pessoas estão realmente usando isso.Eu usei isso no passado em dois projetos.

2.Quais são os prós e contras?
Embora seja difícil resumir em uma pequena lista, aqui estão alguns dos prós e contras que vêm à mente.
Prós:

É fácil fazer com que novos desenvolvedores acelerem.O livro CSLA e o aplicativo de amostra são ótimos recursos para se atualizar.
A estrutura de validação é verdadeiramente de classe mundial - e foi "emprestada" para muitos outros projetos e tecnologias não-CSLA.
Desfazer em n níveis em seus objetos de negócios
Alteração da linha de configuração para escalabilidade de n camadas (Observação:nem mesmo um recompile é necessário)
As principais tecnologias são abstraídas do código “real”.Quando o WCF foi introduzido, teve um impacto mínimo no código CSLA.
É possível compartilhar seus objetos de negócios entre janelas e projetos web.
CSLA promove a normalização de comportamento em vez da normalização dados (saindo do banco de dados para normalização dos dados).

Contras:

Dificuldade em testes unitários
Falta de separação de preocupações (geralmente seus objetos de negócios possuem código de acesso a dados dentro deles).
Como o CSLA promove a normalização do comportamento, em vez da normalização dados, e isso pode resultar em objetos de negócios com nomes semelhantes, mas com finalidades diferentes.Isso pode causar alguma confusão e a sensação de que você não está reutilizando os objetos de maneira adequada.Dito isto, uma vez dado o salto fisiológico, faz mais do que sentido – parece inadequado estruturar os objetos da maneira “antiga”.
Não está “na moda” construir aplicativos dessa maneira.Você pode ter dificuldade para conseguir desenvolvedores apaixonados pela tecnologia.

3.Depois de ler isso, o CSLA realmente não se encaixa no TDD?
Não encontrei uma maneira eficaz de fazer TDD com CSLA.Dito isto, tenho certeza de que existem muitas pessoas mais inteligentes do que eu que podem ter tentado isso com maior sucesso.

4.Quais são minhas alternativas?
O Domain-Driven-Design está recebendo grande impulso no momento (e com razão - é fantástico para algumas aplicações).Há também vários padrões interessantes desenvolvidos a partir da introdução do LINQ (e LINQ to SQL, Entity Framework, etc.).Livro de Fowlers PoEAA, detalha muitos padrões que podem ser adequados para sua aplicação.Observe que alguns padrões estão competindo (ou seja,Active Record e Repositório) e, portanto, devem ser usados em cenários específicos.Embora o CSLA não corresponda exatamente a nenhum dos padrões descritos nesse livro, ele se assemelha mais ao Active Record (embora eu ache que é míope reivindicar uma correspondência exata para esse padrão).

5.Se você parou de usá-lo ou decidiu não usá-lo, por quê?
Não recomendei totalmente o CSLA para meu último projeto porque acredito que o escopo da aplicação é muito grande para os benefícios que o CSLA oferece.
Eu poderia não use CSLA em um projeto web.Sinto que existem outras tecnologias mais adequadas para construir aplicações nesse ambiente.

Em resumo, embora o CSLA seja tudo menos um bala de prata, é apropriado para alguns cenários.

Espero que isto ajude!

Outras dicas

Depois de ler todas as respostas, percebi que algumas pessoas têm alguns conceitos errados sobre o CSLA.

Primeiro, CSLA não é um ORM.Como posso dizer isso com tanta certeza?Porque o próprio Rockford Lhotka afirmou isso muitas vezes em entrevistas no .NET é demais e Hanselminutos podcasts.Procurar qualquer episódio em que Rocky foi entrevistado e ele dirá isso em termos inequívocos.Acho que este é o fato mais importante para as pessoas entenderem, porque quase todos os equívocos sobre o CSLA decorrem da crença de que é um ORM ou da tentativa de usá-lo como tal.

Como Brad Leach aludiu em sua resposta, os objetos CSLA modelam o comportamento, embora possa ser mais correto dizer que eles modelam o comportamento dos dados, uma vez que os dados são parte integrante deles.CSLA não é um ORM porque é completamente independente de como você se comunica com seu armazenamento de dados.Você deve use algum tipo de camada de acesso a dados com CSLA, talvez até um ORM.(Eu faço.Agora uso o Entity Framework, que funciona perfeitamente.)

Agora, vamos aos testes unitários.Nunca tive dificuldade em testar unidades de meus objetos CSLA, porque não coloco meu código de acesso a dados diretamente em meus objetos de negócios.Em vez disso, uso alguma variação do padrão do repositório. O repositório é consumido pelo CSLA, e não o contrário. Trocando um repositório falso para meus testes de unidade e usando o portal de dados local, ESTRONDO! é simples.(Uma vez que o Entity Framework permitir o uso de POCOs, isso será ainda mais limpo.)

Tudo isso vem da compreensão de que CSLA não é um ORM.Pode consumir um ORM, mas em si não é um.

Saúde.

ATUALIZAR

Pensei em fazer mais alguns comentários.

Algumas pessoas disseram que o CSLA é detalhado em comparação com coisas como LINQ to SQL e assim por diante.Mas aqui estamos comparando maçãs com laranjas.LINQ to SQL é um ORM.Ele oferece algumas coisas que o CSLA não oferece, e o CSLA oferece algumas coisas que o L2S não oferece, como validação integrada e npersistência de camada por meio de vários portais de dados remotos.Na verdade, eu diria a última coisa, npersistência de nível superior supera todos eles para mim.Se eu quiser usar Entity Framework ou LINQ to SQL pela rede, tenho que colocar algo como WCF no meio, e isso multiplica enormemente o trabalho e a complexidade, a ponto de eu achar que é muito mais detalhado que CSLA.(Agora, sou fã de WCF, REST e SOA, mas use-os onde realmente precisar, como quando quiser expor um serviço a terceiros.Para a maioria dos aplicativos de linha de negócios, ele não é realmente necessário e o CSLA é uma escolha melhor.) Na verdade, com a versão mais recente do CSLA, Rocky oferece um WCFDataPortal, que eu usei.Funciona muito bem.

sou fã de SÓLIDO, TDD e outros princípios modernos de desenvolvimento de software e use-os sempre que for prático.Mas acho que os benefícios do CSLA superam algumas das objeções dessas ortodoxias e, de qualquer forma, consegui fazer o CSLA funcionar muito bem (e facilmente) com o TDD, então isso não é um problema.

Sim, eu (hum, nós) o usamos extensivamente para modelar nossa lógica de processo de negócios, que era principalmente formulários vinculados a dados em um aplicativo de formulários do Windows.O aplicativo era um sistema de negociação.CSLA foi projetado para estar nessa camada logo abaixo da IU.

Se você pensar em seu aplicativo de linha de negócios complexo padrão, poderá ter um formulário com muitos campos, muitas regras para esses campos (incluindo regras de validação entre campos), poderá invocar uma caixa de diálogo modal para editar algum objeto filho, poderá deseja poder cancelar essas caixas de diálogo e voltar a um estado anterior.CSLA apoia isso.

A desvantagem é que ele tem uma pequena curva de aprendizado.

A principal coisa a lembrar é usar o CSLA para modelar como um do utilizador interage com formulários em algum aplicativo.A maneira mais eficiente para mim foi projetar a UI e entender seus fluxos, comportamento e regras de validação antes de construir os objetos CSLA.Não faça com que seus objetos CSLA impulsionem o design da interface do usuário.

Também achamos muito útil poder usar o lado do servidor de objetos de negócios CSLA para validar objetos enviados de clientes.

Também construímos mecanismos para realizar a validação de forma assíncrona em relação ao serviço da web (ou seja,verificar a faixa de limite de crédito de uma contraparte em relação a um mestre).

CSLA impõe uma forte separação entre sua UI, BusinessLogic e Persistance e escrevemos vários testes de unidade contra eles.Pode não ser estritamente TDD porque você o está direcionando a partir do design da interface do usuário, o que não significa que não seja testável.

A única alternativa real é criar seu próprio modelo/objetos de negócios, mas logo você acaba implementando recursos que o CSLA oferece prontos para uso (INotifyPropertyChanged, IDataErrorInfo, PushState, PopState etc.)

Usei o CSLA para um projeto e funcionou muito bem e tornou as coisas muito mais simples e organizadas.

Em vez de ter sua equipe escrevendo objetos de negócios em seu estilo pessoal diferente, sabemos que temos um padrão comum para trabalhar.

//andy

Tive experiência com isso há vários anos.É uma arquitetura brilhante, mas muito complexa, difícil de entender ou mudar, e está resolvendo um problema que a maioria de nós que desenvolve aplicativos baseados na Web não necessariamente tem.Ele foi desenvolvido mais para aplicativos baseados em Windows e para lidar com desfazer em vários níveis, com grande ênfase na lógica transacional.Você provavelmente ouvirá pessoas dizerem que, como os aplicativos da Web são solicitação-resposta no nível da página, isso é inapropriado, mas com aplicativos da Web no estilo AJAX, talvez esse argumento não seja tão válido.

Ele tem um modelo de objeto muito profundo e pode demorar um pouco para realmente entender isso.É claro que muita coisa pode mudar em poucos anos.Eu estaria interessado em ouvir outras opiniões recentes.

Considerando tudo isso, não seria minha primeira escolha de arquitetura.

Em defesa do CSLA, embora eu concorde com muitos dos comentários que foram feitos, especialmente o de teste unitário...

Minha empresa o utilizou extensivamente para um aplicativo de entrada de dados do Windows Forms, com alto grau de sucesso.

Ele forneceu funcionalidades prontas para uso que não tínhamos tempo ou experiência para escrever por conta própria.
Padronizou todos os nossos objetos de negócios, facilitando a manutenção e reduzindo a curva de aprendizado para nossos novos desenvolvedores.

No geral, eu diria que quaisquer problemas que isso causou foram mais do que superados pelos benefícios.

ATUALIZAR:Além disso, ainda o usamos em nosso aplicativo de formulários do Windows, mas experimentos com seu uso em outros aplicativos, como sites, mostraram que talvez seja muito complicado quando você não precisa de muitas de suas funcionalidades e agora estamos investigando um peso mais leve opções para esses cenários.

Entrei para uma equipe onde o CSLA é obrigatório.Não usamos o portal de dados remoto, que é a única razão pela qual concordo com o uso desta estrutura.Nunca acreditei na ideia do CSLA, então talvez seja por isso que não tenho nada além de problemas com ele, desculpe.

Alguns dos problemas:

Não preciso de um obstáculo entre meu código e o framework .NET, que é o que esse framework parece para mim.Eu tinha uma opção limitada de objetos de lista, mas apenas tive que ignorar os objetos de lista rica no framework .NET.

É totalmente ridículo termos essas listas somente leitura e depois listas não somente leitura.Então, se eu tivesse que adicionar um item à lista, teria que recriar a lista inteira... está falando sério?

Então csla deseja gerenciar o estado do meu objeto, o que é bom, mas nada é realmente exposto.Às vezes, quero alterar o estado de um objeto manualmente, em vez de buscá-lo novamente, o que parece ser o que o csla quer que eu faça.Basicamente, acabo criando muitas propriedades para expor opções às quais o csla achava que não deveria ter acesso direto.

Por que não posso simplesmente instanciar um objeto?Acabamos criando métodos estáticos que instanciam um objeto e o devolvem... você está brincando comigo?

Verifique o código-fonte da estrutura e parece muito pesado para o código de reflexão.

Razões para usar csla:

a estrutura .net direta é poderosa demais para você.
seus desenvolvedores não são experientes e não conseguem entender o conceito de padrões, então o csla terá praticamente todos na mesma página.
1. Não preciso de um obstáculo entre meu código e o framework .NET... Estou preso a esses objetos de lista.

Começamos a usar CSLA porque pensamos que ajudaria em nossa camada de modelo.Foi meio exagero e basicamente tudo o que usamos agora é a classe SmartDate, só porque já estamos vinculados à biblioteca.

Achamos que a interface de validação realmente nos ajudaria a impor regras de negócios, mas não funcionou bem com WCF e serialização (ainda estamos presos na versão 2.0.3.0, então as coisas podem ter mudado).

Não é para tirar o CSLA da lista, mas antes de usá-lo pesquise os benefícios e certifique-se de que eles realmente se aplicam.Sua equipe será capaz de implementá-lo de forma correta/consistente?É necessária comunicação remota e dança de portal?

Acho que além de todas as ponderações teóricas, trata-se de código limpo/manutenível/extensível/testável seguindo padrões básicos comprovados.

Contei as linhas de código necessárias em um domínio específico de um projeto convertido de CSLA.Entre todos os diferentes objetos CSLA (combinações somente leitura+editáveis+raiz+lista) e seus procs armazenados, foram necessárias cerca de 1700 linhas, versus uma implementação Linq2SQL + Repositório que ocupou 180 linhas.A versão Linq2SQL consistia principalmente em classes geradas que sua equipe não precisa consumir livros para entender.E sim, usei o CodeSmith para gerar as partes CSLA, mas agora acredito no código DRY com bits de responsabilidade única, e a implementação do CSLA agora me parece o herói de ontem.

Como alternativa, gostaria de sugerir uma análise do Linq2Sql/Entity Framework/NHibernate combinado com os padrões Repository e UnitOfWork.Dê uma olhada em http://www.codeplex.com/backgroundmotion

Saúde!

Nossa empresa praticou CSLA em alguns de seus projetos e alguns dos projetos legados continuam sendo CSLA.Outros projetos se afastaram dele porque o CSLA violou uma regra OOP pura e simples:Princípio da Responsabilidade Única.

Os objetos CSLA são autossustentáveis, por ex.recuperam os seus próprios dados, gerem o seu próprio comportamento, salvam-se.Infelizmente, isso significa que seu objeto CSLA médio tem pelo menos três responsabilidades - representar o modelo de domínio, conter regras de negócios e conter definição de acesso a dados (não o DAL, ou implementação de acesso a dados, como afirmei/sugeri anteriormente), tudo ao mesmo tempo tempo.

Usamos CSLA extensivamente.Existem vários benefícios;primeiro, acredito que todo desenvolvedor de linha de negócios deveria ler o livro de Rocky Lhotka sobre programação de Business Objects.Pessoalmente, descobri que ele está entre meus três melhores livros de programação de todos os tempos.CSLA é uma estrutura baseada neste livro e seu uso dá ao seu projeto acesso a funcionalidades de alto nível, como desfazer em n níveis, regras de validação e arquitetura de escalabilidade, ao mesmo tempo que fornece os detalhes para você.Observe que eu disse “fornecer” e não “esconder”.Descobri que a melhor parte do CSLA é que faz você entender como todas essas coisas são implementadas até o código-fonte, sem obrigar você mesmo a reproduzi-las.Você pode optar por usar quantos recursos precisar, mas descobri que, ao permanecer fiel aos padrões de design da estrutura, você realmente evita problemas.--Byron

Já usamos o CSLA há mais de cinco anos e achamos que ele funciona muito bem para construir aplicativos de negócios.Juntamente com a geração de código, você pode criar objetos de negócios em um período de tempo relativamente curto e concentrar seus esforços no carne do aplicativo.

Uso CSLA desde vb5, quando era mais uma coleção de padrões do que um framework.Com a introdução do .NET, o CSLA se transformou em uma estrutura completa, que veio com uma curva de aprendizado robusta.No entanto, o CSLA aborda muitas coisas que todos os desenvolvedores de negócios tendem a escrever em algum momento (dependendo do escopo do projeto):lógica de validação, lógica de autenticação, funcionalidade de desfazer, lógica suja, etc.Todas essas coisas você obtém gratuitamente em uma estrutura agradável.

Como outros afirmaram, sendo uma estrutura, força os desenvolvedores a escreverem lógica de negócios de maneira semelhante.Também força você a fornecer um nível de abstração para sua lógica de negócios, de modo que não usar uma estrutura de UI como MVC, MVP, MVVM não se torne tão importante.

Na verdade, eu diria que a razão pela qual tantos desses padrões de UI são tão elogiados hoje (no mundo Microsoft) é que as pessoas têm feito coisas incrivelmente erradas por tanto tempo (isto é, usando DataGrids em sua UI, espalhando sua lógica de negócios em qualquer lugar.tisk tisk).Projete sua camada intermediária (lógica de negócios) corretamente desde o início. Você pode reutilizar sua camada intermediária em QUALQUER UI.Formulário Win, ASP.NET/MVC, Serviço WCF, WPF, Silverlight**, Serviço Windows, ....

Mas, além disso, a grande recompensa para mim foi a capacidade integrada de escalabilidade.O CSLA usa um padrão de proxy que pode ser configurado por meio do seu arquivo de configuração.Isso permite que seus objetos de negócios façam chamadas remotas de servidor para servidor, sem precisar escrever um único código.Adicionando mais usuários ao seu sistema?Não tem problema, implante seus objetos de negócios CSLA em um novo servidor de aplicativos, faça uma alteração na entrada do arquivo de configuração e BAM!!Necessidades de escalabilidade instantânea atendidas.

Compare isso com o uso de DTOs, armazenando sua lógica de negócios no cliente (seja qual for o cliente) e tendo que escrever cada um de seus próprios métodos CRUD como métodos de serviço.CARAMBA!!!Não estou dizendo que esta é uma abordagem ruim, mas eu não gostaria de fazer isso.Não quando existe uma estrutura disponível para fazer isso essencialmente por mim.

Vou reiterar o que outras pessoas disseram: CSLA NÃO é um ORM.CSLA força você a fornecer dados aos seus objetos de negócios.Eles não se importam onde você obtém seus dados.Você pode usar um ORM para fornecer dados aos seus objetos de negócios.Você também pode usar ADO.NET bruto, outros serviços (RESTFUl, SOAP), planilhas excel, posso continuar aqui.

Quanto ao seu suporte ao TDD, também nunca tentei usar essa abordagem com o CSLA.Adotei a abordagem em que modelo minha camada intermediária (como objetos de negócios) usando diagramas de classe e de sequência, na maioria das vezes permitindo que o design de caso de uso, tela e/ou processo seja ditado.Talvez um pouco antiquado, mas a UML sempre me serviu muito bem em meus esforços de design e desenvolvimento.Projetei e desenvolvi com sucesso aplicativos muito grandes e escaláveis que ainda são usados hoje.E até que o RIA do WCF amadureça, continuarei usando o CSLA.

** com algumas soluções alternativas

Sou novo no CSLA, mas entendo os conceitos e já entendo que não é uma ferramenta ORM, então parem de bater nessa maldita bateria, pessoal.Gosto de alguns recursos do CSLA, mas usá-los parece um pouco como se houvesse um mágico por trás da cortina.Eu acho que se você não se importa em não saber como funciona, você pode usar os objetos e eles funcionam bem.

Há uma grande curva de aprendizado para iniciantes e acho que seria muito benéfico ter de 5 a 15 minutos.vídeos como os da Microsoft para aprender os fundamentos.Ou que tal lançar um livro complementar com o código em vez de liberar o código e levar meses para lançá-lo?Apenas dizendo Sr. Lohtka...Começamos a construir nossas coisas antes do livro e eu lutei o tempo todo.Mas como eu disse, sou novo nisso.

Usamos CSLA.Fizemos com que nossos objetos se ajustassem ao molde e depois usamos 10% do que a estrutura oferecia.Desfazer nível de objeto?Não usei.Flexibilidade da camada?Não usei.Acabamos escrevendo códigos de regras de negócios suficientes para que eu pensasse que a única coisa que conseguiríamos com o CSLA era a complexidade.Alguns desenvolvedores "há muito experientes" que conhecem a estrutura a usaram como martelo porque tinham um prego que precisava ser batido.O CSLA estava em seu poder e meu palpite é que muitos proponentes da estrutura também veem as coisas dessa perspectiva.

Acho que nossos desenvolvedores experientes estão felizes porque tudo faz sentido para eles.Eu acho que se sua organização não tem programadores novatos e vocês ficam entediados em escrever objetos POCO simples e eficientes com padrões bem formados, então vá em frente.Utilize CSLA.

Estou usando CSLA como estrutura de objeto de negócios para um projeto de médio porte.A estrutura percorreu um longo caminho desde os dias do VB6 e oferece uma extraordinária flexibilidade e funcionalidade "pronta para uso".Os objetos inteligentes móveis do CSLA tornam o desenvolvimento da UI muito mais fácil.No entanto, concordo com outros que não é a ferramenta certa para todas as situações.Definitivamente, há alguma sobrecarga envolvida, mas também muito poder.Pessoalmente, estou ansioso para usar o CSLA Light com Silverlight.

Prós:

Agnóstico em tecnologia de dados¹
Grande base de instalação e é GRÁTIS!!
Estrutura estável e lógica
O código de acesso a dados pode estar em seus objetos ou em um assembly separado
Validação e Autorização de Propriedade e Objeto

Contras

O código pode ser muito difícil de manter²
Provavelmente precisará de um gerador de código para usar de forma eficaz
Curva de aprendizado.A estrutura dos objetos CSLA é fácil de entender, mas as advertências podem causar dores de cabeça.

Não tenho certeza sobre o design orientado a testes.Eu não faço testes unitários ou design orientado a testes (que vergonha), então não sei se os testes unitários são diferentes do TDD, mas sei que a versão mais recente do framework vem com testes unitários.

¹ Ainda bem porque as tecnologias de acesso a dados nunca permanecem as mesmas por muito tempo.
² Isso ficou melhor com versões recentes do framework.

Muitas pessoas recomendam usar a geração de código com CSLA.Eu recomendo verificar nosso conjunto de modelos suportados, pois eles aumentarão imensamente seu ROI.

Obrigado -Blake Niemyjski (autor do Modelos CodeSmith CSLA)

Usei-o para um projeto há alguns anos.Mas quando o projeto terminou, não pude contar a ninguém o que o CSLA fez por mim.Claro, herdei de suas aulas.Mas consegui remover essa herança de quase todas as classes sem nenhuma reestruturação.Não tínhamos utilidade para o material N-Tier.O desfazer do nível n foi tão lento que não pudemos usá-lo.Então acho que no final isso só nos ajudou a modelar nossas aulas.

Dito isto, outras equipes começaram a usá-lo (após uma tentativa horrível de uma equipe de criar sua própria estrutura).Então tem que haver algo que valha a pena, porque eles são todos mais espertos que eu!

Eu sou um cara de PHP.Quando começamos a construir aplicativos de escala comparativamente grande com PHP, comecei a pesquisar vários frameworks de aplicativos e ORMs essencialmente no mundo PHP, depois em Java e .NET.A razão pela qual também olhei para os frameworks Java e .NET não foi para usar cegamente qualquer framework PHP, mas primeiro tentar entender o que realmente está acontecendo e que tipo de arquitetura de nível empresarial existe.

Como não usei CSLA em uma aplicação do mundo real, não posso comentar seus prós e contras, mas o que posso dizer é que Lhotka é um dos raros pensadores - não estou dizendo apenas especialista - na área de Arquitetura de Software.Embora o nome Domain Driven Design tenha sido cunhado por Eric Evans - a propósito, seu livro também é ótimo e eu humildemente aconselho a lê-lo - Lhotka vem aplicando o Domain Driven Design há anos.Dito isto, independentemente do que você pense sobre sua estrutura, beneficie-se de suas ideias profundas na área.

Você pode encontrar suas palestras em dotnetrocks.com/archives.aspx e vídeos em dnrtv.com/archives.aspx (pesquise por Lhotka).

@Byron Quais são os outros dois livros que você gostou?

John,

Temos equipes trabalhando em CSLA de 2 a 3.5 e achamos que é uma ótima maneira de fornecer uma estrutura consistente para que todos os desenvolvedores "façam da mesma maneira".É ótimo que a maior parte do código de baixo valor seja gerado e sabemos que quando executamos testes de unidade eles funcionam imediatamente para todo o material CRUD.Descobrimos que nosso TDD realmente vem com a refatoração que fazemos para projetar, e o CSLA não nos impede de fazer nada disso.

Chris

A última vez que tentei usar o CSLA foi na época da Idade da Pedra do VB6.Em retrospecto, teria sido mais eficaz se eu tivesse usado a geração de código.Se você não tiver ferramentas eficazes de geração de código e uma estratégia para ajustá-las ao seu fluxo de trabalho, você deve evitar estruturas como CSLA, caso contrário, os recursos que você obtém do CSLA não compensarão a quantidade de tempo que você gasta escrevendo n linhas de código por tabela, n linhas de código por coluna, etc.

Eu usei o CSLA.NET em alguns projetos agora, ele teve mais sucesso em um aplicativo Windows Forms que possui compatibilidades avançadas de ligação de dados (que os aplicativos asp.net não possuem).

Seu principal problema é o suporte a TDD, como as pessoas têm apontado, isso se deve ao comportamento de caixa preta para as funções Dataportal_XYZ e à incapacidade de nos permitir zombar dos objetos de dados.Tem havido esforços para contornar esta questão com esse sendo a melhor abordagem

Eu queria usá-lo, mas meu desenvolvedor líder teve a ideia de que havia muita 'mágica' envolvida...

CSLA é a melhor estrutura de aplicação que existe.Rocky LHotka é um cara muito, mas muito inteligente.Ele está escrevendo a história do desenvolvimento de software como Martin Fowler, David S Platt, mas meus escritores favoritos são Rod Stephens, Mathew mcDonalds Jeff Levinson thearon willis e Louis Davidson alias dr sql.:-) Prós:Todos os padrões de design são aplicados.Contras:Difícil de aprender e poucas amostras.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow