One of the most dangerous lines of code isn’t the one that throws an exception — it’s the one that hides a decision.

As engineers, we often celebrate flexible methods: a single save() that “magically” knows when to insert or update, a send() that picks the right channel, or an approveOrReject() that decides the outcome. At first, it feels convenient. But hidden behind that convenience lives complexity, ambiguity, and a growing army of if-statements.

The problem with too many ifs is not only code readability. It’s that each of the multiple scenarios your team must design, test, and maintain. What looks like “just one more condition” can easily become exponential in cost.

Over time, I’ve adopted a design approach I call the ifless principle: instead of burying decisions in code, we make them explicit in the design of the API and in the domain itself.

The Ifless Principle

The idea is simple:

• Don’t let your service decide what the user already knows.
• Express different operations as different methods, commands, or entities, even if they initially share behavior.
• Move intelligence into rich domain entities (following Domain-Driven Design), so that rules live where they belong.

In short: ifless is not about eliminating ifs, but about putting decisions in the right place.

Example 1: Save vs Insert/Update

If-full version:

public void save(Order order) {
    if (order.getId() == null) {
        insert(order);
    } else {
        update(order);
    }
}

Ifless version:

public void insert(Order order) { ... }
public void update(Order order) { ... }

Even if both methods are identical today, the design already anticipates that inserts and updates will evolve differently. More importantly, the caller knows the intent, so the service doesn’t have to guess.

Example 2: Approvals

If hidden in the service:

public void approveOrReject(Transaction tx, boolean approve) {
    if (approve) { ... } else { ... }
}

Ifless API:

public void approve(Transaction tx) { ... }
public void reject(Transaction tx) { ... }

Each operation has its own lifecycle, rules, and evolution. Tests become more focused, and the API expresses intention clearly.

Example 3: Notifications

Conditional channel selection:

notificationService.send(user, message, channel);

Ifless separation:

emailNotification.send(user, message);
smsNotification.send(user, message);
pushNotification.send(user, message);

Instead of one method with multiple branching conditions, each channel implements its own rules. Adding a new channel doesn’t mean touching a giant switch-case.

Connection with Domain-Driven Design

In Domain-Driven Design (DDD), the domain model encapsulates the core logic. That means invariants (like “an order can only ship if it is paid”) should live inside the entity itself:

public class Order {
    public void ship() {
        if (!this.isPaid()) {
            throw new BusinessException("Order must be paid before shipping");
        }
        // proceed with shipping...
    }
}

Notice: there’s still an if — but it’s not scattered across services. It’s encapsulated in the place where the rule truly belongs: the Order entity.

This is ifless in spirit: decisions are modeled explicitly in the domain, not left to a god-service to decide.

Benefits of the Ifless Principle

1. Clarity of API

The method name tells you exactly what it does. No hidden branching.

2. Reduced Test Explosion

Each if doubles the number of possible execution paths. Removing ifs from services simplifies test design.

Example: save() with insert/update needs at least 2 test suites; insert and update each need only 1.

3. Evolution without Risk

As requirements diverge, methods evolve independently. You don’t risk breaking insert logic while changing update.

4. Alignment with SRP (Single Responsibility Principle)

One method = one reason to change.

5. Cleaner Architecture

Services stay thin. Entities stay rich. Decisions are explicit.

Trade-offs and Counterpoints

No principle is universal. Ifless comes with its own costs:

• Verbosity: You might end up with more methods or services, even when differences are minimal.
• Client Burden: Sometimes, callers just want a convenient save(). Exposing too much detail can reduce ergonomics.
• Breaking conventions: Frameworks like Hibernate and Spring Data already assume methods like save() or merge(). Going against the grain might surprise new developers.

That’s why I see ifless not as a dogma, but as a compass. Use it when clarity, testability, and explicit design outweigh the convenience of a single method.

Related Ideas and References

• Eric Evans – Domain-Driven Design
• Martin Fowler – Refactoring: Replace Conditional with Polymorphism
• Clean Code by Robert C. Martin
• The “UPSERT” debate in SQL — convenience vs explicitness.

Conclusion

Every if has a cost. Not just in code complexity, but in testing, maintenance, and evolution.

The ifless principle is about making decisions explicit in the design of your API and your domain. It’s about contracts that express intent without ambiguity.

It doesn’t mean you’ll never write an if. It means your architecture won’t hide them in the wrong places.

In the age of scaling startups with fewer resources, clarity in design is not a luxury — it’s survival.

Why throwing people at a project often backfires

Brooks’s law identifies three fundamental reasons why adding more people to a software project can actually slow it down:

1. Ramp‑up time. New team members need time to learn the codebase and context. Experienced developers must stop what they’re doing to train newcomers, temporarily reducing productivity . In some cases, new hires even introduce bugs while still ramping up, pushing the project further from completion .
2. Communication overhead. Coordination paths grow exponentially as the team grows. Each person must keep others informed, creating more meetings, emails and stand‑ups . The Nuclino blog visualizes this: a three‑person team has three communication links, but adding three more members increases the links to fifteen .
3. Limited divisibility of tasks. Not all work can be partitioned into smaller pieces. Some tasks demand sequential design and integration. Brooks points out that many software tasks are inherently indivisible . The two‑pizza‑team article expands this: you can’t simply split a complex design problem into tiny independent tickets and expect the result to emerge organically .

These forces mean that there is an upper limit to the productivity gains you can achieve by simply adding developers. At some point, coordination costs and integration complexity outweigh the benefit of having more hands on deck.

The case for small, focused teams

For decades, agile practitioners have advocated small, cross‑functional teams. Jeff Bezos famously framed Amazon’s two‑pizza team rule: if a team cannot be fed with two pizzas, it is too big . The rationale is that small teams minimize communication overhead, allow rapid decision‑making, and foster accountability. Harvard psychologist J. Richard Hackman also warned that larger groups suffer from process problems and dysfunctional dynamics.

Research backs this up. Mike Cohn cites a study in which teams were asked whether their group was too large to achieve the best result. Nearly everyone agreed that teams become inefficient above five members . Analysing over 1,000 software projects, Kate Armel found that projects delivered by teams of four or fewer developers were far more cost‑efficient and had fewer defects than those built by larger teams . The data suggests that four to five people is a sweet spot for most agile projects.

My own “magic number”: three developers

After years of experimenting with different team compositions working as CTO at eits.com.br, I’ve discovered a pragmatic variation on this theme: three developers can deliver remarkable results during a two‑week sprint. With trios, communication paths are minimal (three links), the team can self‑organize without excessive coordination, and everyone has a clear sense of ownership. It’s easier to maintain shared context, perform peer reviews, and collaborate closely on design decisions. If you add more people, you inevitably introduce hand‑offs and waiting, and the time spent aligning increases faster than the productive time gained.

This isn’t just about efficiency — it’s about creativity. Complex problem‑solving often benefits from deep focus and uninterrupted thought. When more developers are involved, everyone gravitates toward smaller sub‑tasks, and the holistic view of the solution can get fragmented. A trio can tackle architecture, coding and testing collaboratively while still preserving big‑picture coherence.

Constraints outside the team

Adding developers doesn’t just create internal coordination issues; it also assumes that there is enough parallelizable work to keep everyone busy. In practice, business requirements, product design and stakeholder input often limit throughput. If there aren’t enough well‑defined tasks, additional engineers either wait idle or start working on poorly defined work, increasing rework later. Similarly, creativity and solution design don’t scale linearly. Some problems require brainstorming and iterative design cycles that don’t benefit from extra hands.

Mitigating the urge to scale up

How can leaders resist the instinct to “manpower their way” out of a schedule slip? Here are some strategies:

• Invest early. Brooks noted that adding developers late in a project is particularly harmful . If you anticipate needing more people, bring them in early when ramp‑up costs are easier to absorb.
• Focus on talent, not headcount. Adding one highly experienced developer may yield more benefit than hiring several junior engineers. Good programmers require less ramp‑up and introduce fewer defects .
• Prioritize architecture and requirements. Many delays stem from unclear requirements or architectural flaws. Spend time up front clarifying what needs to be built and how pieces will fit together. This reduces integration challenges later.
• Keep teams autonomous. When multiple small teams work in parallel, ensure their interfaces are well-defined to minimize cross-team dependencies. Jeff Bezos’ decentralization mantra and the two‑pizza rule were born from this philosophy.

Conclusion

The baby metaphor endures because it cuts to the core of software project dynamics: you can’t compress all tasks simply by adding more people. There is a natural limit to how much work can be parallelized; beyond that, communication overhead, ramp‑up time and cognitive load drag the project down. Research suggests that small teams — typically four to five people — are optimal , and my own experience shows that three developers often deliver the best trade‑off between speed, quality and creativity.

Before you attempt to “scale up” your team to meet a deadline, ask whether the extra hands will actually move the delivery forward or whether they’ll simply add more complexity. Sometimes the most effective strategy is to empower a small, focused team, give them clear goals, and trust them to deliver.

Já está nas bancas o meu mais novo artigo sobre Java e Flex na revista Java Magazine!

O nome do artigo é Integrando Flex com Java utilizando o BlazeDS, e como o título já diz, este artigo é para quem quer aprender integrar o Flex com Java.

Foi escrito de forma bem detalhada com vários exemplos, incluindo a utilização dos serviços de mensageria do BlazeDS.

Já está nas bancas meu artigo sobre Java e Flex na revista Java Magazine!

O nome do artigo é Interfaces de qualidade com Adobe Flex. Ele é voltado para quem não conhece nada, ou está começando à aprender Flex e conhece um pouco de Java.

No artigo Faço uma analogia entre a Linguagem ActionScript 3.0 e Java 5, apresento algumas formas de consumir dados e também como fazer que um código feito para executar na Web com o Flash Player, possa ser executado no Desktop sem alterar uma linha de código funcional.

Estou por finalizar um próximo artigo, nesse o foco está em apresentar como utilizar o Flex em aplicações corporativas, integrando com SpringFramework e EJBs utilizando o JBoss.

Sem mais, por favor deixe o seu feedback!

Abraços.

o/

Assim como os outros meios de comunicação do Flex ( HttpService, WebService, RemoteObject ) o Consumer e Producer precisam de uma funcionalidade no back-end, em específico o DataService que está usando. Como por exemplo, no Java o DataService mais comum que contém essa funcionalidade é o Live Cycle Data Services e o BlazeDS, este OpenSource. No PHP, tem o WebOrb for PHP.

Como o título deste tópico informa, para provar que é muito simples trabalhar com mensageria no Flex, vamos criar um chat com nem 20 linhas (um total de linhas programadas e não de configuração) no Flex. Para tal façanha, primeiro escolha qual linguagem e DataService que irá utilizar no back-end. Eu estarei utilizando Java + BlazeDS.

Partindo do princípio que o BlazeDS já está integrado ao Java e com as configurações básicas:

1. O primeiro passo é criar um canal de comunicação para trafegar as mensagens. Para isso, no arquivo services-config.xml do BlazeDS, adicione o seguinte canal:

   [xml]

   [/xml]

   Esse é um canal de Streaming, e só irá funcionar se for executado em Http 1.1. Outra forma de utilizar os serviços de menssageria, é criar um canal AMF normal (AMFChannel) e ativar o polling, como no exemplo abaixo:

   [xml]

   true

   [/xml]

2. Criado o canal, vamos criar o destination na qual irá utilizar o canal. Para isso, crie se não existir um arquivo no mesmo diretório do services-config.xml com o nome de messaging-config.xml, nele coloque o seguinte conteúdo:

[xml]

[/xml]

Com o messaging-config.xml criado, é preciso informar ao services-config.xml que existem destinations de mensageria. Para isso adicione as linhas abaixo no services-config.xml:

[xml]

…

…

[/xml]

3. Adicionado o destination (chatMessage), a configuração já está completa. Vamos agora criar a Interface do Chat junto com o Producer e Consumer (menos de 20 linhas):

   [xml]

   [/xml]

Pronto! agora basta startar seu Container Web (no meu caso o TomCat) e abrir 2 browsers distintos e enviar as menssagens.
Atenção com o Firefox, pois ele armazena a mesma session para abas diferentes, e por default, o BlazeDS suporta uma conexão por cliente.

Para todo e qualquer erro, verifique sempre o console do Tomcat, ele sempre traz informações úteis para identificar os erros.

[Download do Fonte]

Why Flex

WhyFlex

WhyAIR

Why AIR
Because is Rocks!

Why Flex
Because is Rocks (GuitarPro Version)

Why Flex

Why AIR

Why Flex

Why FlashPlayer?

Why Flex?
By IgorCosta

Mais videos:
http://www.youtube.com/results?search_query=Why+Flex
http://www.30onair.com/all/

Abraços

o/

Minhas principais contribuições para a comunidade:

Post: Configurando Ambiente com Flex 2 e HelloWorld.
Por que ele é relevante: Aprenda a montar um ambiente de desenvolvimento com Flex 2 e um HelloWorld.
A quem ele se destina: Desenvolvedores inexperientes com Flex.

Post: Simples Leitor de RSS
Por que ele é relevante: Veja como em poucas linhas de código é possível fazer um leitor de RSS com Flex usando HttpService.
A quem ele se destina: Desenvolvedores Flex em geral.

Post: Adobe Flex – Brincando com Efeitos
Por que ele é relevante: Veja como é fácil adicionar efeitos aos componentes Flex.
A quem ele se destina: Desenvolvedores Flex em geral.

Post: Trocando objetos entre Flex e PHP
Por que ele é relevante: Faça uso de uma boa prática trocando objetos do tipo VO/DTO/TO entre Flex e PHP via RemoteObject.
A quem ele se destina: Desenvolvedores Flex que usam PHP no back-end.

Post: Censo Adobe Flex Developer
Por que ele é relevante: Um pequena aplicação em Flex que armazena dados de desenvolvedores Flex.
A quem ele se destina: Desenvolvedores Flex em geral.

Post: Trabalhando com CSS no FlexBuilder 3
Por que ele é relevante: Aprenda como criar estilos no Flex através de .css usando o FlexBuilder 3.
A quem ele se destina: Desenvolvedores Flex que tem foco em design.

Post: Proposta de Arquitetura com Adobe Flex e PHP usando Zend Framework
Por que ele é relevante: Disponibilizo a comunidade uma proposta de desenvolvimento com Flex e PHP, para que possa padronizar, arquitetar o código usando boas práticas.
A quem ele se destina: Desenvolvedores Flex que usam PHP no back-end.

Post: Fórum FlexBrasil
Por que ele é relevante: Uma alternativa a listas Flex-Brasil e FlexDev, e armazenamento de tópicos com intenção de ajudar novos desenvolvedores Flex.
A quem ele se destina: Desenvolvedores Flex em geral.

Post: Integrando Adobe Flex + BlazeDS + SpringFramework + Hibernate. [Parte1]  [Parte2]
Por que ele é relevante: Mostro com detalhes como integrar frameworks de mercado mais famosos no mundo Java com Flex usando RemoteObjects.
A quem ele se destina: Desenvolvedores Flex que usam Java no back-end.

E agora eu passo a bola para o Eberton Consolim…

Primeiro lugar, quero agradecer a todos pelo feedback do post anterior, isto é motivante e me dá ânimo em concluir este, e outros que virão.

Hoje o foco deste artigo é que você termine ele sabendo:

Configurar os Beans do Spring através de annotations;

Integrar o esquema de Beans do Spring com os services do Flex através de uma Factory;

Configurar o Spring para usar o Hibernate para abstrair nosso banco de dados;

Para isso vamos a uma breve introdução a estes poderosos frameworks

Breve Introdução ao Spring

Como não sou fã de ficar re-escrevendo a roda, vou tentar dar a você leigo em Spring, um caminho para estudar.

Primeiro de tudo, leia este artigo feito pelo Phillip Calçado (Shoes)
apostila-spring.pdf 
Valeu Ebertom pela hospedagem! =)

Uma Introdução ao que o  SpringFramework pode oferecer:
http://blog.fragmental.com.br/2005/08/31/spring-em-acao/
http://www.ime.usp.br/~reverbel/SMA/Slides/seminarios/spring.pdf
http://imasters.uol.com.br/artigo/4497/java/spring_framework_introducao/

Outros Tutoriais
http://www.javafree.org/content/view.jf?idContent=46

http://www.devmedia.com.br/articles/viewcomp.asp?comp=6627
http://www.devmedia.com.br/articles/viewcomp.asp?comp=6628
http://www.devmedia.com.br/articles/viewcomp.asp?comp=6653

Spring Annotations
http://blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-spring/
http://weblogs.java.net/blog/seemarich/archive/2007/11/annotation_base_1.html

Exemplos de códigos
http://paulojeronimo.com/arquivos/tutoriais/tutorial-spring-framework.zip
http://www.java2s.com/Code/Java/Spring/CatalogSpring.htm

Documentação
The Spring Framework – Reference Documentation

Bom acredito que se você que está afim de conhecer o SpringFramewok, com esses Link’s já é possível entender quase tudo o que ele pode oferecer a sua arquitetura. Lembrando que não é recomendável seguir com este artigo, sem antes entender como funciona  IoC, AOP, DAO, com o SpringFramework.

*Nota A abordagem aqui é sobre o SpringFramework, (Framework de Negócio) e não sobre o SpringMVC, uma vez que o Flex pode se trocar objetos através do protocolo AMF3, é totalmente dispensável o uso de Frameworks MVC’s.

Breve Introdução ao Hibernate

Como eu já disse, uma vez que já existe um bom conteúdo sobre Hibernate na Internet, não há a necessidade de re-escrever, por isso vou lhe dar a você leigo em Hibernate uma sequência de Link que irá te ajudar a entender este poderoso Framework.

Uma Introdução ao que o  Hibernate pode oferecer:
http://www.students.ic.unicamp.br/~ra007271/docs/white-papers/hibernate-uma_introducao_dirigida.pdf
http://www.guj.com.br/java.tutorial.artigo.125.1.guj
http://www.jeebrasil.com.br/mostrar/4
http://www.devmedia.com.br/articles/viewcomp.asp?comp=4149

Outros Tutoriais
http://simundi.blogspot.com/2007/09/criar-uma-aplicao-com-hibernate.html
http://www.hibernate.org/hib_docs/v3/reference/en/html/queryhql.html
http://www.hibernate.org/hib_docs/tools/reference/en/html/plugins.html
http://www.guj.com.br/posts/list/7249.java

Pacotão de PDF’s
http://br.groups.yahoo.com/group/java-br/files/Hibernate/

Exemplos de código
http://www.java2s.com/Code/Java/Hibernate/CatalogHibernate.htm

Documentação
http://www.hibernate.org/hib_docs/v3/reference/en/html/

Ok, partindo do princípio que você já entendeu como funciona o Hibernate, e o Spring, vamos ao código! +)

Requerimentos:

SpringFramework 2.5 ou superior;
*Vamos baixar o Spring com as dependências, isto é neste arquivo conterá todas as libs que nós podemos por ventura usar com o Spring, como por exemplo as libs do hibernate.

MySql 5.x Instalado;
*Eu estarei usando o pacote apache friends – xampp

MySql JConnector 5.x.x;

Conhecimentos básicos sobre MySql;

Plugin Eclipse SpringIDE;
*Opcional

Plugin Eclipse Hibernate Tools 3.2.x;
*Opcional

Instale os plugin’s estes opcionais na verdade este artigo não fará uso deles, mas pensando no futuro seria interessante fazer uso deles.

Após isso, abra seu projeto no Eclipse que nós tinhamos criado anteriormente, O JavaFlex.

Vamos adicionar as seguintes libs ao projeto na pasta JavaFlexWebContentWEB-INFlib:

*A maioria das libs podem ser encontrada no arquivo compactado que você baixou do Spring. Lembrando também que o modelo de estilo de projeto criado no Eclipse, Dynamic Web Project, já adiciona automaticamente ao Classpath do projeto ao você colar as libs nesta pasta.

Como nós já tinhamos modelado um caso de uso chamado Cargo, vamos agora criar um banco de dados para o nosso pequeno sistema.

Abra seu MySql, e execute este script sql que criará a base de dados chamada JavaFlex, e também a tabela JAVAFLEX_CARGO;

--
-- Banco de Dados: `javaflex`
--
CREATE DATABASE `javaflex` DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
USE `javaflex`;

--
-- Estrutura da tabela `javaflex_cargo`
--

CREATE TABLE `javaflex_cargo` (
  `ID_CARGO` int(10) unsigned NOT NULL auto_increment,
  `DS_CARGO` varchar(50) collate utf8_unicode_ci NOT NULL,
  PRIMARY KEY  (`ID_CARGO`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

Entendendo os Pacotes, e configurando a persistência

Com o banco de dados criado, vamos mapear a tabela no banco, com o nosso Entity Cargo, para isso, crie um package chamado:

com.digows.artigos.JavaFlex.model.repository.hibernate.hbm

Neste package irá conter todos os nossos mapeamentos em xml, alguns preferem fazer uso de annotations, só que pessoalmente não gosto de acoplar códigos de annotations em meus beans de negócio, prefiro delegar a função Mapeamento a arquivos xml’s.

Neste mesmo package crie um arquivo chamado Cargo.hbm.xml, e adicione o seguinte conteúdo:

Cargo.hbm.xml

[xml]

[/xml]

Perceba que estamos mapeando nosso entity Cargo que foi criado no post anterior com a tabela  JAVAFLEX_CARGO criada recém.

com.digows.artigos.JavaFlex.model.repository.hibernate

Este package irá conter classes que implementam o Pattern DAO usando o Hibernate. Métodos de CRUD e querys em geral usando o Hibernate deverão estar neste pacote estes separados por casos de uso.

Neste mesmo package, vamos criar um DAO usando o hibernate para o nosso entity cargo, para isso, crie uma classe java chamada CargoHibernateDao,  e adicione o seguinte conteúdo:

CargoHibernateDao.java

[java]

package com.digows.artigos.JavaFlex.model.repository.hibernate;

import java.util.List;

import org.hibernate.SessionFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.orm.hibernate3.support.HibernateDaoSupport;
import org.springframework.stereotype.Repository;

import com.digows.artigos.JavaFlex.model.entity.Cargo;
import com.digows.artigos.JavaFlex.model.repository.CargoRepository;

@Repository(value=”cargoRepository”)
public class CargoHibernateDao extends HibernateDaoSupport
implements CargoRepository {

@Autowired
public CargoHibernateDao(@Qualifier(“sessionFactory”)SessionFactory factory) {
super.setSessionFactory(factory);
}

public Cargo save(Cargo p_cargo) {
getHibernateTemplate().saveOrUpdate(p_cargo);
return p_cargo;// ID POPULADA
}

public void remove(Cargo p_cargo) {
getHibernateTemplate().delete(p_cargo);
}

public Cargo findById(Cargo p_cargo) throws Exception {
long id = p_cargo.getIdCargo();
p_cargo = (Cargo) getHibernateTemplate().get(Cargo.class, p_cargo.getIdCargo());

if (p_cargo == null)
throw new Exception(“O Cargo com a ID: “+id+” do(a) “+Cargo.class.getSimpleName()+” não foi encontrada.”);
return p_cargo;
}

@SuppressWarnings(“unchecked”)
public List getList() {
return (List) getHibernateTemplate().loadAll(Cargo.class);
}
}

[/java]

Perceba que esta implementa apenas métodos de acesso ao banco de dados usando o hibernate. Nesta classe faço uso de annotations para que o container Spring faça o wire dos beans.

@Repository

A anotação @Repository é mais um estereótipo que foi introduzido no Spring 2.0. Esta anotação é usada para indicar que uma classe funciona como um repositório (Veremos mais adiante o que é este pattern), esta anotação faz com que o Spring envie Exceptions da persistência a camada de serviço, vindas de DataAccessException, isto é deixa tranparênte a camada de serviço o tipo de repository que foi implementado.

@Autowired

A anotação @Autowired é usada para a injeção de depêndencia da sessionFactory do hibernate.

@SuppressWarnings

Faço uso da anotação @SuppressWarnings, apenas para o compilador não gerar um Warning no cast da List, uma vez que o Hibernate foi projetado sem o uso de Generics, ao usar Generics o compilador devolve um Warning.

Perceba que esta classe implementa uma interface, está interface implementa o pattern Repository, este padrão já causou muita polêmica em forums Java como o GUJ por exemplo, recomendo a leitura deste post para entender o padrão:
http://blog.caelum.com.br/2007/06/09/repository-seu-modelo-mais-orientado-a-objeto/

com.digows.artigos.JavaFlex.model.repository

Este package irá conter interfaces do tipo repository que dará comportamentos a DAO’s sejam elas implementadas por DAO’s Hibernate, DAO’s JDBC, DAO’s iBatis e etc…

Neste mesmo pacote, crie uma interface chamada CargoRepository com o seguinte conteúdo:

CargoRepository.java

[java]

package com.digows.artigos.JavaFlex.model.repository;

import java.util.List;
import com.digows.artigos.JavaFlex.model.entity.Cargo;

public interface CargoRepository {

void remove(Cargo p_cargo);
Cargo save(Cargo p_cargo);
Cargo findById(Cargo p_cargo) throws Exception;
List getList();
}

[/java]

Ok! nossa persistência já foi programada, vamos agora alterar a classe CargoService que foi criado no post anterior, para que se comporte como uma classe de serviço gerenciada pelo container Spring.

Para isso, altere o nome da classe CargoService que está no package com.digows.artigos.JavaFlex.model.service para CargoServiceImpl e adicione este conteúdo:

CargoServiceImpl.java

[java]

package com.digows.artigos.JavaFlex.model.service;

import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;

import com.digows.artigos.JavaFlex.model.entity.Cargo;
import com.digows.artigos.JavaFlex.model.repository.CargoRepository;

@Service(value=”cargoService”)
@Transactional(propagation=Propagation.REQUIRED, rollbackFor=Exception.class)
public class CargoServiceImpl implements CargoService {

private CargoRepository cargoRepository;

@Autowired
public void setCargoRepository(CargoRepository cargoRepository) {
this.cargoRepository = cargoRepository;
}

public Cargo save(Cargo p_cargo) throws Exception {
try {
this.cargoRepository.save(p_cargo);
return p_cargo;
} catch (Exception e) {
throw new Exception(“Não foi possível salvar.” +e.getCause());
}
}

public void remove(Cargo p_cargo) throws Exception {
try {
this.cargoRepository.remove(p_cargo);
} catch (Exception e) {
throw new Exception(“Não foi possível excluir.” +e.getMessage());
}
}

public Cargo findById(Cargo p_cargo) throws Exception {
try {
return this.cargoRepository.findById(p_cargo);
} catch (Exception e) {
throw new Exception(“Não foi possível procurar pela ID.”+e.getMessage());
}
}

public List getList() throws Exception {
try {
return this.cargoRepository.getList();
} catch (Exception e) {
throw new Exception(“Não foi possível listar.”+e.getMessage());
}
}
}

[/java]

Perceba que é uma classe de serviço simples, esta apenas tem a funcão de coodernar os Entities de domínio e fazer a persistência atráves de um repository.

@Service

A anotação @Service é uma forma especializada da anotação @Component. É conveniente anotar as classes da camada de serviço com @Service para facilitar o processamento por ferramentas ou antecipar qualquer futuro serviço de capacidades específicas que podem ser adicionados a esta anotação.

@Transactional

Como o próprio nome diz, é um estereótipo que delega ao container que esta classe de serviço deve ser transicional.

@Autowired

A anotação @Autowired é usada para a injeção de depêndencia que será feita pelo container de uma implementação da interface CargoService.

Nessa camada de serviço faço uso também do Pattern DIP (Dependency Inversion Principle), por isso esta classe é uma implementação (CasoDeUsoServiceImpl) de uma interface de serviço, no caso a CargoService.

Para isso no pacote com.digows.artigos.JavaFlex.model.service, crie uma interface com o nome de CargoService, com este conteúdo:

CargoService.java

[java]

package com.digows.artigos.JavaFlex.model.service;

import java.util.List;

import com.digows.artigos.JavaFlex.model.entity.Cargo;

public interface CargoService {

void remove(Cargo p_cargo) throws Exception;
Cargo save(Cargo p_cargo) throws Exception;
Cargo findById(Cargo p_cargo) throws Exception;
List getList() throws Exception;
}

[/java]

Ok, com estes passos realizados, já concluímos a implementação do nosso model. A estrutura final deverá ser esta:

Configurando o SpringFramework com o Hibernate e o Blaze.

No post anterior, configuramos o Tomcat para utilizar apenas o BlazeDS, agora precisamos adicionar mais as configurações  do SpringFramework.

Para isso abra o arquivo JavaFlexWebContentWEB-INFweb.xml e altere deixando com este conteúdo:

web.xml

[xml]

JavaFlex

contextConfigLocation

/WEB-INF/applicationContext.xml

org.springframework.web.context.ContextLoaderListener

org.springframework.web.context.request.RequestContextListener

flex.class.path
/WEB-INF/flex/hotfixes

MessageBrokerServlet
MessageBrokerServlet

flex.messaging.MessageBrokerServlet

services.configuration.file
/WEB-INF/flex/services-config.xml

flex.write.path
/WEB-INF/flex

1

MessageBrokerServlet
/messagebroker/*

index.html
index.htm
index.jsp

[/xml]

Perceba na configuração do Spring, ele faz referência a um arquivo chamado applicationContext.xml, este arquivo é o que contém as configurações do Spring em si, então no mesmo diretório que se econtra o web.xml, crie um arquivo com o nome de applicationContext.xml e coloque este conteúdo:

applicationContext.xml

[xml]

${jdbc.driverClassName}

${jdbc.url}

${jdbc.username}

${jdbc.password}

classpath:com/digows/artigos/JavaFlex/model/repository/hibernate/hbm/

org.hibernate.dialect.MySQLInnoDBDialect

true
<!–
Atualizar o Banco de dados de acordo com os arquivos de mapeamentos.
update
–>

[/xml]

Perceba que as configurações do banco de dados usado, delego a um arquivo .properties, também vou precisar configurar o log4j para a impressão de log’s. Por estética o bacana seria gerar um novo source-path que contenha tais arquivos properties.

Crie um pasta na raiz do projeto com o nome de resources,

De um botão direito sobre o projeto e clique em properties;

Em Java Build Path, clique no botão AddFolder;

Selecione a pasta resources, clique em ok, e marque a opção Allow output folders for source folders, e ok.

Dentro do package resources, crie um arquivo chamado jdbc.properties, e adicione o seguinte conteúdo:

jdbc.properties

# Properties file com as configuracoes do JDBC.
# Aplicado pelo PropertyPlaceholderConfigurer do Spring

jdbc.driverClassName=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/javaflex
jdbc.username=root
jdbc.password=

#Properties que determina o dialeto do Banco de Dados.
hibernate.dialect=org.hibernate.dialect.MySQL5InnoDBDialect

e outro arquivo chamado log4j.properties com este conteúdo:

log4j.properties

### direct log messages to stdout ###
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

# set root logger level to debug and its only appender to mtf
log4j.rootLogger=INFO,development

# only for development purposes
log4j.appender.development=org.apache.log4j.ConsoleAppender
log4j.appender.development.layout=org.apache.log4j.PatternLayout
log4j.appender.development.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %5p [%t] (%F:%L) - %m%n

log4j.logger.noModule=FATAL
log4j.logger.org.springframework=WARN

# Log JDBC bind parameter runtime arguments
log4j.logger.org.hibernate.type=DEBUG

Uma outra modificação é necessária, está a mais importante, pois delega ao Blaze, que existe uma factory de beans criada pelo Spring.

Essa factory deve ser implementada, porém já existe pronto na internet para uso, esta pode ser encontrada aqui:

Spring and Flex Integration Factory Class

Baixe ela, e coloque por exemplo neste pacote:

com.digows.artigos.JavaFlex.controller

*O  nome controller ficou sugestivo aqui, uma vez que está factory não tem comportamentos de um controller, porém como o Flex não faz uso do controller para controlar as actions que também não existe, achei bacana preservar o package colocando a factory de beans do Spring que será usada pelo Blaze neste pacote. Se alguém tiver uma idéia melhor de onde colocar a classe, estou aceitando opniões.

Vamos então configurar o Blaze. Abra o arquivo JavaFlexWebContentWEB-INFflexservices-config.xml e altere deixando com este conteúdo:

services-config.xml

[xml]

false

[BlazeDS]
true
false
true
true

Endpoint.*
Service.*
Message.*
DataService.*
Configuration

true
20

{context.root}/WEB-INF/flex/services-config.xml

{context.root}/WEB-INF/flex/remoting-config.xml

{context.root}/WEB-INF/web.xml

[/xml]

Perceba que mapeio o local da Factory. Agora é preciso atualizar nosso servico cargoService dentro do arquivo JavaFlexWebContentWEB-INFflexremoting-config.xml. Então abra e edite deixando com este conteúdo:

remoting-config.xml

[xml]

spring
cargoService

[/xml]

Aqui só é importante observar que a tag <source /> mapeia o nome do bean do tipo serviço que foi delegado na annotation, no nosso caso na classe CargoServiceImpl perceba a annotation @Service(value=”cargoService”) e também a tag <factory /> que faz referência a configuração no arquivo services-config.xml

Se tudo foi efetuado corretamente, ao você dar um botão direito no projeto e ir em Run As -> Run On Server, ao clicar em salvar no fomulário de cadastro criado no post anterior, o seu objeto cargo vindo do Flex já será persistido! observe o console para isso.

Eu alterei o arquivo comdigowsartigosJavaFlexviewscreenCargoForm.mxml para que possa usar todos os métodos do CRUD Cargo. Segue como ficou:

CargoForm.mxml

[xml]

[/xml]

Bom pessoal, acredito que com estes 2 artigos consegui atingir o objetivo de dar a comunidade Java uma proposta de interface produtiva e poderosa, e também a comunidade Flex uma proposta de uma arquitetura com Flex e Java, utilizando o Blaze Data Services.

Faça mais testes, veja que o desenvolvimento é muito rápido! muito melhor do que se matar com tags html e funções em JavaScript.

Fora que você pode desenvolver com o Flex aplicando os conceitos de Orientação a Objetos, a começar pela tranferência de dados, no Flex chega Objetos! e não textos (XML, WebServices, Request/Response e afins).

Neste artigo não fiz uso de patterns para o desenvolvimento das telas em Flex, porém nos próximos artigos irei abordar detalhadamente como você pode arquiteturar seu código Flex visando ganhar manutenabilidade, escalabilidade, e reusabilidade.

Tópico no Forum que contém detalhes sobre o download. Flex 2.0 e Flex 3.0
[Link]

Obrigado a todos e um Beijão especial para minha querida Liz!

=*****

Abraços

o/

Hoje vou começar algo que estou prometendo há um bom tempo! A integração dos seguintes frameworks:

Adobe Flex;

Adobe BlazeDS;

Spring Framework;

Hibernate;

Introdução

No mundo de desenvolvimento WEB principalmente com Java, temos problemas quanto ao desenvolvimento de interfaces, como incompatibilidade entre browsers, desenvolviemento lento, e outros detalhes que muitos vivenciam diariamente.

Existem soluções que prometem como o JSF por exemplo, mas como dizem “A primeira experiência em Flex o programador Java nunca esquece.” logo quero convidar você que vem do mundo do Java, para conhecer uma solução de desenvolvimento de interfaces com o AdobeFlex.

Apresentando Adobe Flex e Adobe BlazeDS

Adobe Flex

Do Flex não vou falar muito, também por que neste blog você pode encontrar muito conteúdo explicativo como por exemplo este link: http://23.20.48.222/?p=32 algumas abordagens ali já estão desatualizadas, porém a essência é a mesma como por exemplo algumas vantagens de se usar Flex:

O Flex é executado a partir de uma máquina virtual, logo o programador apenas se preocupa em desenvolver a interface não em programar compatibilidade entre browsers.

Você programa sua interface totalmente orientada a objetos, isso visa reuso de componentes, desenvolvimento de módulos e afins.

Há várias maneiras de comunicar o Java com o Flex, mas em destaque é que você pode trocar objetos Java/Flex por um protocolo que provê compactação e tranferência binária, este é o AMF.

Adobe BlazeDS

O BlazeDS é um produto OpenSource (Licença LGPL v3) que corresponde à tecnologia JAVA server-side que dá suporte tanto para o Remoting assim como ao Messaging de objetos trocados entre o Java e o Flex/Flash.

Com o BlazeDS você pode gerar vários tipos de canais de conexão, um destaque muito importante para toda a comunidade Flex/Flash mundial, é que o serviço de data-push também foi disponibilizado de graça!, para quem não conhece, é algo semelhante ao Pattern Observer.

Integrando o Adobe Flex com o BlazeDS

Requerimentos:

Eclipse 3.3;

Adobe Flex Builder 3 Plugin;
*No título apresento como solução OpenSource, e o FlexBuilder 3 é pago, mas irei fazer uso apenas para facilitar o entendimento, caso seja estudante, baixe o FlexBuilder 2 é de graça para estudantes ou afins, caso não, baixe o Flex SDK e compile com Ant ou com o FlashDeveloper que é de graça.

Adobe BlazeDS;
*É recomendável que baixe a documentação do BlazeDS, para futuros estudos.

Tomcat 6.0;

Ok, Vamos começar!

Extraia o Eclipse 3.3 em algum lugar, por exemplo C:/Desenvolvimento/Eclipse 3.3/

Instale o Plugin do Flex no Eclipse, quando pedir o local aonde instalar o flex sdk, você pode selecionar em C:/Desenvolvimento/Frameworks/Adobe/

Após baixado o BlazeDS, perceba que ele vem vários arquivos, o que importa agora são os seguintes:

blazeds-samples.war

blazeds.war

No blazeds-samples.war como o próprio nome diz, contém aplicações de exemplo, como implementação do data-push, um chat, e etc…

O blazeds.war contém tudo o que é necessário para podermos configurar nossa aplicação.

Você deve ter percebido que no arquivo que você baixou o BlazeDS, contém um Tomcat já com todas as libs necessárias e etc.. Algumas libs ali tem reelevância como a flex-tomcat-common.jar e flex-tomcat-server.jar mas vamos deixar isso para outro artigo =)

Apesar do BlazeDS já vir com um Tomcat, eu estarei usando meu próprio Tomcat 6.0.

Abra seu Eclipse, e faça como no screencast abaixo que mostra como criar seu projeto no Eclipse 3.3:

Link Externo

*Se na aba “Problems” estiver com o erro “Cannot create HTML wrapper. Right-click here to recreate folder html-template.” clique com o botão direito, e clique em Recreate HTML Templates. Considero isso um bug do FlexBuilder.

Com o projeto criado, vamos adicionar as libs necessárias para a execução do BlazeDS, para isso abra o blazeds.war (Com um Winrar da vida) e copie todos os Jars contidos na pasta WEB-INFlib para o nosso projeto na pasta WebContentWEB-INFlib.

Com as Libs adicionadas, vamos criar um serviço no java que servirá como exemplo de como o Flex pode acessar uma classe java através do BlazeDS.

Para isso na pasta src_java, crie uma estrutura de pacotes, por exemplo:

com/digows/artigos/JavaFlex/model/service/
com/digows/artigos/JavaFlex/model/entity/

Dentro do package entity crie uma classe java com o nome de Cargo com o seguinte conteúdo:

Cargo.java
[java]

package com.digows.artigos.JavaFlex.model.entity;

public class Cargo {

private long idCargo;
private String dsCargo;

public long getIdCargo() {
return idCargo;
}
public void setIdCargo(long idCargo) {
this.idCargo = idCargo;
}
public String getDsCargo() {
return dsCargo;
}
public void setDsCargo(String dsCargo) {
this.dsCargo = dsCargo;
}
}

[/java]

Entities (ou Entidades, nenhuma relação com Entity Beans) são objetos que possuem uma identidade única.

Um carrinho de compras numa loja virtual web não é igual a outro, não importa que possuam os mesmos produtos, o carrinho A é o carrinho do usuário A, o carrinho B é do usuário B. Mesmo que contenham os mesmos produtos você não pode exibir o carrinho B ao usuário A, eles são diferentes! O carrinho neste exemplo segue o Padrão Entity, ele é uma entidade de negócios única.

Dentro do package services crie uma classe java com o nome de CargoService com o seguinte conteúdo:

CargoService.java
[java]

package com.digows.artigos.JavaFlex.model.service;

import java.util.ArrayList;
import java.util.List;

import com.digows.artigos.JavaFlex.model.entity.Cargo;

public class CargoService {

public Cargo save(Cargo p_cargo) {
System.out.println(“Salvou o Cargo: “+p_cargo.getDsCargo());
return p_cargo;
}

public void remove(Cargo p_cargo) {
System.out.println(“Excluiu o Cargo: “+p_cargo.getDsCargo());
}

public List getList() {
return new ArrayList();
}

public Cargo findByPrimaryKey() {
return new Cargo();
}
}

[/java]

Services são classes que não implementam diretamente as regras de negócio da aplicação, apenas coordenam a interação entre os componentes, elas são quase sempre beans gerenciados pelo Spring. É muito importante que as classes do tipo Services não implementem as regras de negócio, elas apenas atuam como Façades coordenando as interações.

O CargoService claro não proverá persistência a um banco de dados, os sysouts ali são apenas para abstração da intragração.

Com as classes javas feitas, vamos a configuração dos channels do BlazeDS, para isso no web.xml contido dentro da pasta WebContentWEB-INFweb.xml, deixe como mostrado abaixo:

web.xml

[xml]

ArquiteturaJavaFlex

MessageBrokerServlet
MessageBrokerServlet

flex.messaging.MessageBrokerServlet

services.configuration.file
/WEB-INF/flex/services-config.xml

flex.write.path
/WEB-INF/flex

1

MessageBrokerServlet
/messagebroker/*

index.html
index.htm
index.jsp

[/xml]

Perceba que ao gerar a Servlet Java, é passado por parâmetro um arquivo dentro da pasta WebContentWEB-INFflex, crie um arquivo chamado services-config.xml como referênciado, este arquivo é o que contém Factorys, Channels, LogConfigs. Nós vamos usar apenas um tipo de serviço que o BlazeDS implementa, que o canal de AMF3 simples, para isso adicione o seguinte conteúdo:

services-config.xml

[xml]

false

[BlazeDS]
false
false
true
false

<!–Endpoint.*–>
<!–Service.*–>
Message.*
DataService.*
Configuration

true
20
{context.root}/WEB-INF/flex/services-config.xml
{context.root}/WEB-INF/flex/remoting-config.xml
{context.root}/WEB-INF/web.xml

[/xml]

Perceba que é feito um include em um arquivo chamado: remoting-config.xml, então crie um arquivo com este nome na pasta WebContentWEB-INFflex. Este arquivo contém alguns adapters, e nossos destinations, que nada mais é que o mapeamento das nossas classes de serviços no java. Para isso adicione o seguinte conteúdo:

remoting-config.xml

[xml]

com.digows.artigos.JavaFlex.model.service.CargoService

[/xml]

A estrutura deverá ficar igual apresentado abaixo:

Para testar se tudo está ok, de um botão direito sobre o Projeto JavaFlex, e clique em Run As -> Run on Server. Na proxima janela aberta, em server runtime deixe seleciona o “Apache Tomcat v6.0“ e clique em finish, o Servidor irá iniciar, observer a aba Console para verificar possíveis erros. Se alguma Exception tiver ocorrida, verifique os passos e faça novamente.

Acessando o serviço Java através do remoting do BlazeDS

Como nosso serviço já foi levantado, basta gerarmos um form simples para testar nosso serviço, para isso na pasta src_flex, crie a seguinte estrutura de pastas:

com/digows/artigos/JavaFlex/view/entity/
com/digows/artigos/JavaFlex/view/screen/

Dentro do package Entity crie uma Classe ActionScript com o nome de Cargo com o seguinte conteúdo:

Cargo.as
[as]

package com.digows.artigos.JavaFlex.view.entity
{
[RemoteClass(alias=”com.digows.artigos.JavaFlex.model.entity.Cargo”)]
[Bindable]
public class Cargo
{
public var idCargo:Number;
public var dsCargo:String;
}
}

[/as]

A Classe Cargo do Flex, é nada mais nada menos do que o espelho do Entity do java, nesta classe não realizei get’s set’s. Para fazer o espelho dos objetos usei a metatag [RemoteClass] mapeando a localização exata (Com package e nome da Classe) da mesma classe no java. A metatag Bindable é uma annotation muito importante, mais agora vamos apenas abstrair ela.

E dentro do package Screen, crie um arquivo MXML com o nome de CargoForm com o seguinte conteúdo:

CargoForm.mxml

[xml]

[/xml]

Perceba que acoplei muito código neste arquivo, isto não é uma boa prática, nos próximos artigos irei desaclopar as responsabilidades em camadas.

Para testar se tudo está ok, no arquivo JavaFlex.mxml que está na raiz da pasta src_flex renomeie para index.mxml, de um botão direito e clique em Set as Default Application, e deixe ele com o seguinte conteúdo:

index.mxml

[xml]

[/xml]

E para finalizar vamos dizer ao compilador do Flex que existe um servidor de AMF levantado, para isso de um botão direito no projeto JavaFlex -> Properties -> Selecione Flex Compiler -> em Additional compiler arguments adicione a linha e ok:

-services “../WebContent/WEB-INF/flex/services-config.xml”

Para Executar, de um botão direito sobre o projeto JavaFlex, e clique em Run As -> Run on Server e Finish.

Se tudo correr bem, você verá a descrição que você digitou no flex aparecerá no console do Tomcat.

Bom finalizo aqui a primeira parte desta poderosa integração, logo logo posto o resto.

Link do Source do Projeto:
Download

Abraço Pessoal!!

o/

Te Amuh Liz!! =******

=)

É com muito prazer que divulgo a todos que o forum sobre AdobeFlex ficou pronto! Está bem bacana, utilizamos o PhpBB3 que veio com um layout muito mais atrativo.

http://forum.flexbrasil.com.br/

O forum tem a intenção de unir mais a comunidade, e está voltado para aqueles:

1. Que não conhece a tecnlogia;
2. Que estão começando a aprender;
3. Que já estão em um nível avançado;

Acredito que ficou muito bom, pesso que entre e confira!! e também divulguem para que a comunidade cresça  o mais rápido o possível!

Abraços e até mais!

o/