Por que não o framework Spring? [duplicado]

Como outros posts aqui mencionam o lado positivo, mencionarei os aspectos negativos da Spring. Mesmo com esses aspectos negativos, a Spring é onipresente em seu nicho, confiável e funciona como anunciado.

Então, para os negativos:

• Enorme: Eu não gostaria de colocar frascos com 3000 classes em meu pequeno projeto de hobby.

• Existem algumas descrições mais lentas do que algumas outras estruturas de DI, como Guice ou Pico. anedótica e provavelmente não muito importante.

• Lidar com algumas partes da primavera pode ser frustrante quando não estão bem documentadas partes do núcleo e a documentação que você encontra diverge nas várias versões principais.

Como um efeito colateral de seu tamanho, prepare-se para passar horas alegres explorando pilhas de classes que, embora chamadas logicamente, começam a se fundir em uma gigantesca pilha de nomes quando você está cansado ("claro, basta conectar TransactionAwareConnectionFactoryProxy para seu UserCredentialsConnectionFactoryAdapter para seu .. zzzzzzzz "). Para ser justo, eles são logicamente nomeados, é uma resposta razoável ao tamanho do framework, mas ainda assim.

Possivelmente como resultado dessa adaptação de novas peças, a primavera pode ser lenta, pelo menos para mim. Não tanto com o núcleo da primavera, mas há conectores para quase tudo, e eles não são tão bem documentados como poderiam ser, e é quando você começa a vasculhar o substantivo. Mais uma vez, é tudo apenas em resposta ao seu tamanho.

Existem muito poucas desvantagens no Spring

Pensei longamente e com afinco para encontrar alguma desvantagem séria em usar o Spring, e estou com medo de ter falhado. Spring é um excelente kit de ferramentas dentro dos modelos JEE / OSGi. Ele fornece uma ampla variedade de modelos não invasivos que simplificam muito o trabalho com as APIs de suporte, que geralmente são complicadas, fornecidas por contêineres de aplicativos.

Primavera versus o núcleo JEE

O Spring não substitui as tecnologias principais do JEE - bem, talvez EJBs, mas com a nova especificação EJB3, praticamente não há nada nele - em vez disso, ele fornece modelos para tornar o uso muito mais fácil. Considere o JAX-RS a API de serviços da Web RESTful. O Spring fornece o RestTemplate , que é normalmente usado da seguinte maneira (suponha que seja injetado):

SomeJaxbAnnotatedClass object = restTemplate.getForObject(someURI,SomeJaxbAnnotatedClass.class);

Isso vai para someURI obter o XML / JSON / YAML e desempenhá-lo no objeto de domínio que você especificar. Tudo em uma única linha de código.

As exceções e o registro de erros são tratados como exceções de tempo de execução, tornando mais fácil manter o código local limpo. O Spring até trabalha para reduzir dependências externas sempre que possível, então o exemplo acima usa apenas os pacotes java.net. *).

Existem modelos para JMS, JAX-WS, JPA, JTA e assim por diante. Todos eles tornam muito mais fácil trabalhar com esses padrões e tornar seu código mais limpo e menos propenso a erros.

Arquitetura Pick'n'mix

Do ponto de vista arquitetônico, o Spring enfatiza uma abordagem leve de pick'n'mix. Isso tem o efeito de permitir que os arquitetos de sistemas evitem o uso de contêineres de aplicativos inchados para todos, como o WebSphere, JBoss ou Glassfish, e escolha suas contrapartes leves em vez disso - Jetty, Tomcat e assim por diante.

Por que isso é importante? Os contêineres de aplicativos maiores têm um ciclo de atualização muito mais longo que atende às necessidades de alguns clientes mais do que outros. Os bancos não precisam ser tão ágeis quanto uma startup de um homem.

Se você quiser usar a versão mais recente de estruturas de suporte, é improvável que você as encontre nos grandes contêineres de aplicativos. Em vez disso, você precisará incluí-los manualmente e o Spring facilita isso.

Além disso, você só precisa incluir especificamente as tecnologias de que precisa. Os contêineres do aplicativo fornecerão JMS, EJB e todos os outros acrônimos sob o sol, mas você só deseja uma persistência fácil com o JPA. Inclua Spring e Hibernate e pronto.

Então, por que não a primavera?

Evite o Spring se você quiser usar as implementações específicas de bibliotecas do fornecedor. Além disso, evite-o se quiser manter seus detalhes de configuração dentro de suas classes, em vez de externá-los em XML ou JNDI. E definitivamente evite se você acha que soluções livres e de código aberto não são adequadas para o seu ambiente.

uma coisa interessante que Martin Thompson menciona em este artigo é que a primavera pode ter um impacto não trivial nos tempos de GC:

Keep call stacks reasonably small. Still more work to do here. If you are crazy enough to use Spring, then check out your call stacks to see what I mean! The garbage collector has to walk them finding reachable objects. -Martin Thompson

Esse tipo de coisa não será um grande problema para a maioria dos tipos de aplicativos, mas é uma preocupação muito real para os tipos de aplicativos aos quais Martin está se referindo.

A primavera é realmente boa. Spring Core está bem. Eu adicionaria aos outros pontos, se você estiver na categoria de nicho onde o desempenho é realmente uma preocupação, você vai querer evitar os outros módulos do Spring, somente se você estiver nas mãos dos principais desenvolvedores. Isso é apenas uma preocupação se você estiver executando um sistema em que o desempenho seja realmente crítico. Nas mãos de desenvolvedores médios e bons, o Spring provavelmente lhe dará um aumento de desempenho ajudando a escrever códigos simples e limpos.

A primavera basicamente se tornou parte da plataforma agora. Em todo lugar no JEE5 e no 6 você encontra mais e mais injeção de recursos, então pelo menos essa parte do Spring, se você ficar com ele, será / será apenas outra parte da plataforma, (veja @Inject). Outras partes ... não tão seguras, especialmente quando se trata de programação orientada a aspectos. Existem outros provedores desses serviços, o Guice, originalmente do Google, e o Weld, do JBoss, acredito que baseado no Guice, fornecerá a mesma funcionalidade se você se ater às especificações de injeção de dependência Java do JSR-330.

YMMV

A Spring se esforça para não ser invasiva em termos de mantê-la fracamente acoplada ao código do seu aplicativo.

Ele também está se movendo mais nessa direção ao longo do tempo. Nas versões anteriores, você precisaria estender as classes base, depois passava para as anotações e hoje em dia é mais e mais uso de POJOs configurados em XML.

Esse é um enorme benefício estratégico em relação a outras estruturas de aplicativos.