matheussi
2006-02-17 16:30:08 UTC
Pessoal, boa tarde.
Gostaria de expor uma idéia e que vc´s dessem suas opiniões. Essa idéia já
foi
criticada no passado de maneira negativa, mas a exaustão me leva a
discutí-la novamente.
Hoje trabalho de uma maneira que, a meu ver, eh pouco produtiva. Um overview
simplificado da arquitetura que eu uso seria:
UI <-> Commands (Command Pattern) <-> Facades <-> Business Obj
A interface envia uma requisicao com um value object e um command name para
o controller e ele localiza o command apropriado.
Nessa forma de trabalho, a UI não tem acesso aos obj de negocio. Ela recebe
e envia Value Objects em suas requisições. Para representar as colecoes de
objetos, uso classes que herdam de CollectionBase nos value objects e classes
que implementam IEnumerable nos objetos de negócio. Percebem? É um tal de
preencher obj de negocio a partir de um value object e vice versa q nao tem
fim.
Alem disso, a escrita de métodos para carregar as colecoes eh pouco
flexivel. As vezes a interface precisa de uma ou duas propriedades do obj
preenchidas apenas. Tenho que ter metodos que carregam os objetos
parcialmente e outros que os carregam por inteiro, uma vez que o load full
dos objetos em uma colecao acaba com a performance.
O que gostaria de discutir seria algo como:
UI <-> FAcades <-> Business Objs
ou, em situacoes simples em que o Facade pode ser descartavel, como em uma
operacao atomica (um load simples ou um save que nao precisa ser
transacionado):
UI <-> Business Objs .
Também deixaria de implementar classes que representam coleçoes de entidades
do sistema e passaria a usar mais datasets e arraylists, por exemplo.
Penso nisso em prol da produtividade no desenvolvimento. Alguém vê algo
realmente impeditivo nessa forma de trabalho?
Gostaria que vc´s comentassem isso, a favor ou não. Estou procurando alguma
alternativa, pois o desenvolvimento aqui está burocrático e demorado demais.
Valeu, galera!
Gostaria de expor uma idéia e que vc´s dessem suas opiniões. Essa idéia já
foi
criticada no passado de maneira negativa, mas a exaustão me leva a
discutí-la novamente.
Hoje trabalho de uma maneira que, a meu ver, eh pouco produtiva. Um overview
simplificado da arquitetura que eu uso seria:
UI <-> Commands (Command Pattern) <-> Facades <-> Business Obj
A interface envia uma requisicao com um value object e um command name para
o controller e ele localiza o command apropriado.
Nessa forma de trabalho, a UI não tem acesso aos obj de negocio. Ela recebe
e envia Value Objects em suas requisições. Para representar as colecoes de
objetos, uso classes que herdam de CollectionBase nos value objects e classes
que implementam IEnumerable nos objetos de negócio. Percebem? É um tal de
preencher obj de negocio a partir de um value object e vice versa q nao tem
fim.
Alem disso, a escrita de métodos para carregar as colecoes eh pouco
flexivel. As vezes a interface precisa de uma ou duas propriedades do obj
preenchidas apenas. Tenho que ter metodos que carregam os objetos
parcialmente e outros que os carregam por inteiro, uma vez que o load full
dos objetos em uma colecao acaba com a performance.
O que gostaria de discutir seria algo como:
UI <-> FAcades <-> Business Objs
ou, em situacoes simples em que o Facade pode ser descartavel, como em uma
operacao atomica (um load simples ou um save que nao precisa ser
transacionado):
UI <-> Business Objs .
Também deixaria de implementar classes que representam coleçoes de entidades
do sistema e passaria a usar mais datasets e arraylists, por exemplo.
Penso nisso em prol da produtividade no desenvolvimento. Alguém vê algo
realmente impeditivo nessa forma de trabalho?
Gostaria que vc´s comentassem isso, a favor ou não. Estou procurando alguma
alternativa, pois o desenvolvimento aqui está burocrático e demorado demais.
Valeu, galera!