Camada de Negócios

Olá pessoal,
sou novo na programação Java mas, estudei bastante sobre o assunto.
Estou começando um projeto novo para Web e resolvi usar JSP/JSTL/Struts para a camada View, DAO para persistência, DTO para objetos que utilizarei para transferência entre camadas e estou em dúvida de como desenvolver minha camada de negócios.
Minha idéia é não usar EJB no momento mas, deixar isso como uma opção no futuro. Para tanto estou criando um pacote com um Command Factory que vai disparar as ações para os meus BOs. Vocês acham isso uma boa idéia? Ou quem sabe eu deveria usar o Spring para encapsular meus objetos de negócio (espero não ter falado uma besteira agora, na verdade não conheço o Spring mas, ví uma matéria na última Mundo Java que mencionava o seu uso desta maneira).
A verdade é que estou meio perdido e um pouco cansado de estudar mais e mais ferramentas e tecnologia sem ter certeza de que caminho seguir. Qual seria a melhor maneira de encapsular meus BO’s sem utilizar EJB?
Agradeço qualquer sugestão.

Primeira pergunta, pra que exatamente você precisa dos DTOs?
Struts é a única opção? Se sim, use ele para o controller e a view, caso contrário, dá uma olhada no Webwork também.

Em relação aos EJB´s, caso a aplicação for distribuída é uma boa pedida, caso contrário não vejo motivo pra sua utilização.

Em relação ao Command Factory, muita atenção, eles são estupidamente necessários? Eu tava modelando uma pseud-arquitetura pra um projeto aqui e iria utilizar Command também, mas vi a tremenda asneira que eu tava fazendo. Já temos uma aplicação aqui utilizando este pattern, e nossa camada de negócios virou um amontoado de objetos procedurais, ou seja, cada um era responsável por uma regra de negócio. Ex: classe IncluirUsuario, classe ExcluirUsuario, classe EfetivarInscricao, etc.

Sugestão: Primeiro modele tuas regras de negócio, estude os Patterns e veja quais se encaixam pra resiolução do teu problema. Patterns são soluções padrões para problemas comuns no sistema, você está tentando arrumar a solução antes de ter o problema. Não faça a mesma burrada que eu, tentando modelar um monte de frameworks e patterns pra aplicação, sem ter os requisitos antes, você vai acabar tendo de adaptar suas regras de negócio aos frameworks e patterns.
Modele os objetos para que eles interajam entre si, e a partir daí pense em frameworks e patterns.

Bom Rafael, primeiramente já vou adiantando que pela falta de experiência em Java, tomei como base casos documentados em artigos que lí a respeito de boas técnicas de programação e casos de sucesso.
Estou fazendo um projeto Web e ví que o Padrão de Mercado é usar o Struts (MVC), por isso resolvi “entrar no onda” já que isso me obrigaria a seguir um layout de projeto mais próximo do que realmente se aplica na maior parte dos casos.

Confesso, realmente estou tentando arrumar a solução antes do problema. Na verdade uma “receita de bolo” para não cair em erros maiores, uma vez que o “Vício” da Programação Procedural me “cega” a ver os objetos de negócio de outra maneira. Toda minha experiência de programação é voltada a linguagens quase puramente procedurais. Ainda não consigo ver o problema de outra maneira daquele que você colocou (classe IncluirUsuario, classe ExcluirUsuario, classe EfetivarInscricao, etc.). Acho que este é um problema comum a quem aprendeu primeiro a programar de forma procedural e depois a programar Orientado a Objetos.

Como eu faço para pensar no problema mais Orientado a Objetos e menos Orientado a Procedures?

O que se costuma utilizar para programar uma camada de negócios que será praticamente operações similares as do DAO (consulta / inclusão / alteração / exclusão / relatórios em cima de um Banco de Dados)?

Ps.: Os DTOs eu estou usando apenas como Value Objects (algumas vezes como Beans) para passar os dados entre uma camada e outra.

Bem, primeiro gostaria de salientar que minha experiência não é tão vasta, por isso recomendo algumas leituras sobre OO, Padrões de Projetos, UML, e etc.
Porém vou dar minha opinião de acordo com o que tenho estudado e aprendido.

Quanto ao Struts, já fiz a mesma coisa que você, comecei a usá-lo porque era padrão de mercado, mas particularmente não gostei muito dele, é um framework bom, mas te obriga a coisas desnecessárias. Sugiro que teste tanto o Struts quanto o Webwork e veja qual melhor atende tua necessidade.

Aqui
Aqui
Aqui
E aqui

Esse são só alguns que vão te ajudar, eu estou utilizando o primeiro e o terceiro, e são muito bons.
Mas secamente falando, tente modelar teu sistema, tuas regras de negócio o mais próximo do mundo real. Tem um conceito que aprendi a pouco que se chama Domain Model, é bem interessante, ele baseia-se em modelar tua camada de negócio conforme um domínio, onde os objetos executam ações e colaboram entre si, porém nenhum objeto tem acesso a implementação do outro, comunicam-se pela sua interface.
Veja aqui

Se seu sistema vai ser somente pega-da-tela-joga-no-banco/pega-no-banco-joga-na-tela, então reveja seriamente a necessidade da utilização de todos esses frameworks, patterns e etc.
Caso seja mais complexo que isso, sugiro que pense primeiramente nas tuas regras de negócio, depois se preocupe com tua persistência e tua view.

Ainda não entendi pra que você precisa desses DTO´s.

Obs:É que o GUJ está fora do ar, mas assim que voltar te passo uns links sobre esses assuntos(Patterns, Arquitetura, Modelagem), que são algumas dúvidas que andei tirando por lá.[/url]