Arquitetura em 3 camadas + camada DTO

[Frederico Ribeiro]

Olá pessoal, gostaria de saber a opinião de vocês a respeito da arquitetura em 3 camadas mais uma camada DTO que tenho adotado no desenvolvimento de aplicações Windows.
Segue em anexo como está meu projeto.

• BLL – Bussiness Logic Layer
• DAL – Data Acess Layer
• UI – User Interface
• DTO – Data Transfer Object

É uma boa prática de programação? Está correto?

Ps: link de onde tirei o exemplo

[Bruno Souza]

Fala Fred, blz?

Eu tava dando uma pesquisada nisso agora de manhã pra um novo projeto que quero iniciar e um vídeo interessante que eu encontrei foi esse: https://www.youtube.com/watch?v=KM5o9M4cuQA

Att,

Bruno Cesar

(61) 8448.4272

“É impossível haver progresso sem mudanças, e quem não consegue mudar a si mesmo não muda coisa alguma.” (George Bernard Shaw)

--
==============================
Comunidade de desenvolvedores Dot Net no Brasil
 
Facebook: www.facebook.com/grupodotnetbr
 
WebSite: www.dotnetbr.com
 
E-mail do Grupo: dotn...@googlegroups.com
==============================
---
You received this message because you are subscribed to the Google Groups "DotNet Brasil" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnet_br+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paulo S. M. Marques]

Só adicionaria a Facade aí, caso queira algum dia usar serviços...

http://pt.wikipedia.org/wiki/Fa%C3%A7ade

--

==============================
Comunidade de desenvolvedores Dot Net no Brasil
 
Facebook: www.facebook.com/grupodotnetbr
 
WebSite: www.dotnetbr.com
 
E-mail do Grupo: dotn...@googlegroups.com
==============================
---
You received this message because you are subscribed to the Google Groups "DotNet Brasil" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotnet_br+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Atenciosamente,

Paulo S. M. Marques - @psmarques - Skype: psmarques
Software Engineer

[Marcelo Acioli Bastos]

@Frederico, Tudo bem?!?!

Nobre, trabalhei com essa abordagem em um passado recente e não tive nenhum problema com ela. Sobre a opinião do @Paulo, adicionar uma Facade, eu criaria uma camada Service, pois a Facade vai ter um conjunto de interfaces, segundo o Pattern FACADE. Já a camada de serviços, como o nome mesmo ja diz, seria exclusiva dos seus Services, seja ele WCF etc.

Não vejo nenhum Problema com DTO, mas deve-se atentar para questões de serialização, ver se sua necessidade será completamente atendida entre outros. Vai exigir alguns cuidados, mas não eh nada de bicho de 7 cabeças e como vc ja trabalha desta forma, acredito que de certo.

Eu tinha um projeto que seria com as camadas:

DTO

Services

DAO -.> DAL

Entidades

Mapeamentos

BO

WEB.UI

E deu certo!!

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

[Gustavo Cruz]

Frederico,

Sem querer ser "indelicado", mas como você nomeia e/ou monta suas camada em nada vai interferir no real funcionamento do seu projeto. A sacada está em como você vai orquestrar isso tudo.

Esse approach é o mais comum que existe (o famoso 3-Tier). Só lembrando que DTO é DTO e deve ser usado pra este fim (transporte simples de dados, flat). Não tente fazer dos DTO´s as suas entidades.

Como não tenho maiores detalhes do seu projeto, não tenho como opinar mais a fundo o que seria uma arquitetura mais interessante pra você.

Gustavo Figueiredo
.NET System Architect
+55 31 9253.5062

[Frederico Ribeiro]

Bom galera valeu aí a atenção muito obrigado, acho que tenho que estudar um pouco mais padrões de projeto as vezes me perco um pouco e fico na dúvida justamente por não
conhecer  a fundo. Se alguém tiver algum material em português fico agradecido. Meus códigos tem melhorado a cada dia mas talvez seja esse um diferencial que ainda falta.
Vou dar uma olhada no padrão Facade e sobre a camada Service, ver se pode ser interessante nesse projeto, valeu pelas dicas.
Obrigado mais uma vez.

[Marcelo Acioli Bastos]

Ratificando o que o @Gustavo falou...o DTO será utilizado para transporte de dados entre suas camadas...não confunda com entidades...veja que da forma como Classifiquei eu tenho uma camada de entidades.

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

[Frederico Ribeiro]

Bom me corrijam se eu estiver errado, mas pelo que entendi a classe DTO tem os atributos de cada objetos e os métodos de acesso get e set,certo?
Dessa maneira no caso de uma consulta ao banco na IU é criado um objeto DTO que recebe os atributos, chama a BLL que tem as regras do negócio que chama a DAL
que acessa o banco e retorna o resultado para a classe BLL que em seguida manda pra UI que exige esses dados, Correto?

No caso de uma camada entidades ela só teria os atributos dos objetos?

[Marcelo Acioli Bastos]

http://www.codeproject.com/Articles/8824/C-Data-Transfer-Object

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

--

[Marcelo Acioli Bastos]

http://msdn.microsoft.com/en-us/library/ff649585.aspx

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

[Marcelo Acioli Bastos]

@Frederico,

Muito cuidado com o DTO, um exemplo pode ser isso:

public class PersonDTO
 {
        public string NIC { get; set; }
        public string FullName { get; set; }
        public string FirstName { get; set; }
        public string BirthPlace { get; set; }
        public string BirthCertificateID { get; set; }
 }

Mas tenha cuidado com o uso do dito cujo.

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

[Gustavo Cruz]

Neste caso você teria um modelo anêmico, portanto, seu DTO será sua entidade.

Se se sentir confortável com essa arquitetura, procure mais exemplos de modelos anêmicos na internet, tem muito material sobre isso.

Gustavo Figueiredo
.NET System Architect
+55 31 9253.5062

--

[Marcelo Acioli Bastos]

@Gustavo,

Foi a palavra que faltou, ANEMICO, mas é isso mesmo.

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

[Frederico Ribeiro]

Pesquisando melhor a respeito do modelo anêmico (não conhecia esse termo) entendi que realmente tenho um modelo anêmico no meu projeto, e pesquisando mais um pouco percebi que
a maioria dos desenvolvedores não recomendam o modelo anêmico por diversos motivos, dentre eles a manutenção do código e que não condiz em alguns aspectos com o que prega a OO.
Considerando que  esse modelo anêmico por enquanto me atenda, mas que irei analisar se o altero para um modelo rico nesse projeto no futuro, Como eu faria?
Retiraria a camada DTO unindo o com a camada BLL onde a mesma ficaria com os atributos do objeto e seus métodos? Basicamente, seria melhor adotar MVC no futuro?

[Marcelo Acioli Bastos]

@Frederico,

Adota o MVC. De preferência o mvc3 ou 4, porém depende de sua arquitetura...framework, orm como voce quer trabalhar.

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

[Antônio Milesi Bastos]

É bem "old school" essa estrutura...

Comece simples... foque em uma arquitetura evolutiva.

Comece com:

SisLab.Domain (Domínio Rico)

SisLab.Web (projeto mvc)

 - Models (Coloque as ViewModels)

SisLab.Data (config do acesso a dados)

Essa é a prática que costumo usar!

Abraço,

Antônio Milesi Bastos

[Frederico Ribeiro]

Antônio não tenho muita experiência em programação web, não entendi muito bem seu exemplo, minha experiência é maior em aplicativos desktop em java e agora c#.
Poderia explicar melhor?

[Frederico Ribeiro]

Obrigado mais uma vez Marcelo vou ler mais sobre o mvc3 e mvc4, e me atualizar.

[Marcelo Acioli Bastos]

@Frederico,

são as camadas que ele usa...DAL, BUS...etc.

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

2014-06-26 15:28 GMT-03:00 Frederico Ribeiro <fredd...@gmail.com>:

Obrigado mais uma vez Marcelo vou ler mais sobre o mvc3 e mvc4, e me atualizar.

--

[Gustavo Cruz]

Frederico,

Para quem não tem muita experiência, não vejo problema algum em utilizar o modelo anêmico. Essa discussão modelo anêmico X modelo rico é uma simples questão de opinião. Tem alguns dev´s que dizem ser um anti-pattern (caso do Fowler), mas isso já foi desmitificado por inúmeras pessoas.

NENHUM pattern é bala de prata. O que adianta você querer implementar um modelo rico (aka Domain-Driven) se não sabe sobre orquestração e divisão de responsabilidades? Se não entende os conceitos de DDD e não tem um conhecimento deep-level de OO? Seu projeto basicamente vai virar um elefante branco.

Sempre, sempre comece pelo simples. 

Quanto ao seu questionamento para evolução em um modelo rico, você deu uma misturada nas coisas aí. DTO não é exclusividade de modelo anêmico, eu apenas disse que usando esse approach suas entidades farão o papel de DTO´s. Não existe problema algum em ter um modelo rico que use DTO´s, aliás isso é até comum.

Pra acabar de vez com a dúvida, segue o conceito de DTO by wikipedia:

The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behavior except for storage and retrieval of its own data (accessors and mutators). DTOs are simple objects that should not contain any business logic that would require testing.

O que acontece é que basicamente hoje, quem faz a validação e aplica a regra de negócio é a sua camada de BLL. Utilizando um modelo rico, essas regras estarão dentro das suas entidades (quando pertencer exclusivamente à estas) e dentro de serviços específicos (quanto correlacionar a várias entidades). 

O que parte daí pra frente é outra coisa, vai depender do pattern que você vai querer utilizar. Inclusive pode manter o DTO, ou utilizar o MVVM, que também não deixa de ser um DTO no final das contas.

Gustavo Figueiredo
.NET System Architect
+55 31 9253.5062

[Gustavo Cruz]

Lembrando que o MVC é apenas para a sua camada de apresentação....comece tentando criar uma arquitetura descente, assim não vai importar o que você vai usar no front, pode ser MVC, webservices, webforms, desktop, REST, o céu é o limite.

Gustavo Figueiredo
.NET System Architect
+55 31 9253.5062

[Otavio Costa]

Galera,

aproveitando o topico, tenho tido uma duvida. Quero comecar a usar TDD mas o sistema onde trabalho é antigo e usa essa estrutura de Serviço, BLL, DAL, DTO e para acesso ao banco, stored procedures. 

A logica, geralmente fica na BLL ("geralmente" isso pq algumas das vezes fica na tela mesmo aspx.cs, eu sei, horrivel)

Como que posso começar a usar testes unitarios? É muita dependencia e nao da pra mockar tudo, tipo, uma BLL pega os dados que passei no DTO, valida e inclui. Nao tenho muita logica pois acaba sendo tudo muito CRUD.

Como voces estao contornando isso? TDD so funciona com arquitetura em Dominio?

Abraços

________________________
Otavio Costa
otavi...@gmail.com

[Marcelo Acioli Bastos]

@Otavio,

Sua vida ta dificil. Realmente estou preocupado com o futuro da aplicação.... kkkk, falando sério.. Ja passei por esta situação e acredito que pra melhorar sua vida primeiro organizar a casa, posteriormente podes iniciar estas abordagens... o TDD você vai ter que ter muita paciência, pois a cultura dos desenvolvedores não eh esta.

Teste unitário também é muito bom, mas voce tem que avaliar para seu caso o que seria melhor. De longe adotaria o Unit test, pois ja usei em cenário parecido e depois de uma boa reformulada ai adotei o TDD. Mas tem que ser com muita cautela.

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

[Antônio Milesi Bastos]

Já que vc está começando...

De uma olhada nessa sacada que gravei sobre Como Iniciar um Projeto ASP .Net MVC, do ZERO e ainda configurar o novo ASP.Net Identity Provider para funcionar com o NHibernate.

Esse é o link:

http://youtu.be/iWmbLmSDoc4

Espero q te ajude!

Abraço,

Antônio Milesi Bastos

[Abner das Dores]

Bom, talvez tenha chegado um pouco tarde na discussão, mas vamos lá, vou dar minhas opiniões aqui.

Serei obrigado a discordar de alguns colegas da lista, mas não considero essa estrutura uma boa prática. Já utilizei essa abordagem e posso dizer que essa abordagem possui um ponto positivo, que é algum nível de separação de responsabilidades, pois fica bem definido o que cada camada faz – ou deveria fazer.

Mas no meu entendimento, para por aí. Quando você possui uma dependência transitiva dessa forma UI -> BLL -> DAL e todos dependendo de DTO, no fundo é como se você tivesse um único boco monolítico, pois você não consegue “trocar as peças”. E não, trocar as peças nesse caso não é simples, pois a partir do momento que na BLL você faz um “dal = new ProdutoDAL()” você está fortemente acoplado aquela implementação. Eu carinhosamente chamo esse pattern de “bolovo”, pois no fundo, está tudo junto, fortemente acoplado.

Outro ponto, é que como alguns colegas citaram, usar DTO’s favorece um modelo anêmico, o que diminui a expressividade que você poderia ter no seu código. Falando ainda sobre expressividade, normalmente esse modelo favorece nomes pouco expressivos como “ProdutoBLL”. Uma boa prática é tentar ao máximo dar nomes significativos aos seus objetos e métodos. Isso normalmente fica muito distante nessa estrutura, pois o que normalmente se vê é um saco de métodos “Salvar”, “Atualizar”, “Deletar”, etc. E o pior normalmente esses métodos não fazem nada e simplesmente delegam uma chamada para a DAL! (Isso quando a DAL não executa uma procedure!)

Ai um outro ponto que eu citaria é essa separação em Class Libraries. Sinceramente, eu só separo em projetos diferentes se tenho um dos casos:

1) Estou construindo uma API’s que vai ser compartilhada em mais de um projeto (Ex: um WCF e uma aplicação MVC)

2) A estratégia de deploy dessa class library será diferente da do meu projeto.

Caso não tenha nenhum desses casos, normalmente eu opto apenas pela separação em namespaces e um bom design na minha aplicação. Isso normalmente favorece uma arquitetura emergente.

“Ahh, mas e se no futuro eu tiver que distribuir essa API de outra forma?” – Se essa necessidade não existe agora e você gastar tempo com isso, é desperdício, simples assim. E se você tiver um bom design na sua aplicação você consegue extrair essas coisas com uma certa facilidade quando a necessidade surgir. No máximo, eu concordo com a abordagem mostrada no vídeo que o Bruno no começo da thread, de separar uma única class library com tudo que realmente não deve ter dependências do projeto web, mas não necessariamente a separação de pastas em Data, Providers, etc. Isso aí vai depender do seu projeto.

Por fim, concordo com o Gustavo nas suas colocações, não existe nenhum pattern que seja bala de prata e vá funcionar em todos os casos, por isso, comece simples e caso tenha algo te incomodando na sua estrutura, mude! Simples assim. Testes (não necessariamente TDD) te ajudam a ter segurança nessa etapa.

Fora isso, eu recomendaria você olhar os princípios SOLID de desenvolvimento de software orientado a objetos e dar uma olhada sobre inversão de controle e injeção de dependência. Talvez não faça sentido agora, mas com certeza isso vai ficar perturbando sua mente, rs.

Att.,

--

Abner das Dores

[Abner das Dores]

Otavio,

Sobre sua pergunta, eu diria que é impossível fazer TDD em um código desses. Dificilmente você conseguiria mockar tudo isso, e o esforço não valeria a pena.

Fora isso, novamente, TDD não é a única saída. O que você precisa é de uma suíte de testes que te de segurança para refatorar (ou reescrever) as partes mais internas da sua aplicação que estão com um design ruim.

Nesses casos, o que eu recomendaria é partir de uma abordagem de fora para dentro. Crie testes de aceitação (que abrem o navegador e tudo), ou integrados (nas suas BLL’s da vida), de forma que você garanta o que já sua funciona. Isso provavelmente será um trabalho muito árduo.

Feito isso, você tem segurança de refatorar as partes mais internas do código, removendo duplicações, extraindo métodos, extraindo classes, interfaces, etc. E nessas extrações, você em algum momento vai conseguir começar a fazer TDD. E inclusive no futuro substituir alguns testes integrados por testes mais simples de unidade.

É um trabalho árduo, e confesso que nunca consegui fazer, pois onde trabalhava e possuía um sistema nesse cenário, não tive espaço para isso.

Mas acredito que o caminho seja por aí, boa sorte!

Att.,

--

Abner das Dores

[Wesley Baldan]

Concordo com tudo que o @Abner das Dores disse, principalmente no que toca a parte SOLID..... 

Mas, antes de mudar qualquer coisa referente a testes.. 

Se vc trabalha em equipe, eu diria que vc primeiramente, terá que conversar com a equipe e ver se eles aceitam a ideia de fazer testes.

Não adianta, vc faz os testes no métodoX, o cara vai lá... muda, e não roda o teste, não faz nada...... ai vc terá vários testes quebrando quando der um get que o cara fez.....

Já passei por várias empresas, devo ter trabalhado com uns 200 programadores, e ainda não tive muita sorte.... Ninguém tá nem ai para nada...... 

[Gustavo Cruz]

Digo, repito e reforço: TDD != Testes.

Eu por exemplo, não utilizo TDD para tudo que vou construir, aliás eu só uso quando vou construir alguma rotina realmente complexa. Tem gente que se sente confortável fazendo até para uma simples classe, mas vai de cada um, eu não me adaptei ao approach xiita 100% TDD.

Agora, testes sim, eu procuro ter testes unitários para praticamente tudo que tem comportamento dentro do meu sistema, fora testes de integração, aceitação, funcionais, etc. e, logicamente, uma rotina de build/deploy que faz a mágica acontecer.

Gustavo Figueiredo
.NET System Architect
+55 31 9253.5062

[Wesley Baldan]

Para testes, só tento levar sempre o esquema de fazer o teste falhar primeiro. Se ele passa sem falhar e eu ainda não implementei, é certo que, algo está errado...... isto valida se meu teste está funcionando corretamente. 

Claro que, as vezes, escrevemos algum teste depois e ele acaba passando devido a alguma implementação anterior..mas para isto, rodo ele isoladamente em modo debug, "para testar se o teste está funcionando corretamente" 8-O

[Frederico Ribeiro]

Bom pessoal como e velho ditado diz: Quando você pensa que sabe alguma coisa descobre que na verdade não sabe é de nada.

Tenho lido a respeito do escreveram  e das dicas e videos que enviaram o link, e realmente estou totalmente convencido que a minha solução para organizar as camadas deixa a desejar,
realmente acabei complicando coisas simples, tem muito código sem utilidade e acabei perdendo tempo repetindo algumas coisas, e como vocês disseram esse modelo acaba tendo muitas desvantagens.

Algum livro que poderiam indicar sobre padrões de projeto que tenham implementações em C#?
Sobre os princípios SOLID de desenvolvimento tem algum livro específico ou nos próprios livros de padrões de projeto vão ter esse conteúdo?

Mais uma vez obrigado a todos por clarear essa mente que a pouco estava confusa.

[Marcelo Acioli Bastos]

@Frederico,

Na boa, adota o mvc3 e usa wcf, pois deste padrão pro mvc3 foi meio impactante, mas eu resolvi um monte de problemas. No meu caso o .net framework 4.0 e NHibernate 3.2 com Fluent. Usamos linq to nhibernate e fizemos uma aplicação distribuida, fisicamente, pois tínhamos esta possobilidade para ter servido de SGDB e de aplicação.

Ve isso e acredito que voce vai consegui administrar bem.

http://www.bufaloinfo.com.br/
http://www.codeproject.com/Articles/434282/A-N-Tier-Architecture-Sample-with-ASP-NET-MVC-WCF
http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3/cs/intro-to-aspnet-mvc-3
http://www.devmedia.com.br/arquitetura-em-camadas-com-c/12037

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

[Abner das Dores]

Frederico, os princípios SOLID são descritos no livro do Uncle Bob - Agile Principles, Patterns, and Practices in C#: http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258

Não li esse livro (ainda), mas já recebi muitas recomendações sobre ele. Se você der uma procurada na internet vai achar bastante coisa relevante sobre o assunto. 

[Wesley Baldan]

Muitos não gostam, mas o Use A Cabeça - Design Patterns eu achei muito bom......
Segue uma lista:

Head First Design Patterns -  Freeman, Eric; Elisabeth Freeman; Kathy Sierra; Bert Bates Domain-Driven Design -  Evans, Eric Clean Code -  Martin, Robert C. The Clean Coder -  Martin, Robert C. Professional Test Driven Development with C#: Developing Real World Applications with TDD -  Bender, James Se vc não manja muito do inglês..... Acho que tirando o último livro da lista, todos os demais tem a versão português..... Aqui tem outros que está na minha lista para leitura futura... http://www.shelfari.com/o1514675512/shelf

[Marcelo Acioli Bastos]

Martin Fowler também é um caminho.

Marcelo Bastos
Analista de sistemas
81-9589-9103
https://marceloaccioly.wordpress.com

[Otavio Costa]

@Marcelo

Tambem estou preocupado! hehehehe... Mudar é algo assim impossivel visto o tamanho do sistema. To a 1 mes na empresa e nao vou me focar em tentar mudar isso aqui... Vou estudar isso pra mim pra projetos pessoais e ter bagagem pra proxima empresa.

@Abner

Minhas duvidas sempre foram se da pra adotar testes unitarios em qq arquitetura. Realmente é impossivel fazer testes direito. As BLL´s quase nao tem "regras de negocio" de verdade e as DAL´s sao proxies pro acesso ao banco atraves de procedures. Os testes acabam sendo de integração mesmo e com uma dependencia de dados no banco absurda! Se for criar um ambiente pro teste, tem que incluir dezenas de tabelas pra testar um evento isolado.... Resumindo, nao vale a pena.

A arquitetura que tenho visto melhor e tenho aplicado nos projetos pessoais é ter um dominio, repositorio, uma camada de servico e uma model pra ir para a UI. Se integra bem com o MVC, com DDD e testes unitarios (e claro, TDD).

Tambem nao achei viavel ser xiita e meter 100% de cobertura de testes. Voce acaba ficando paranoico e o sistema simplesmente nao anda.

Acho que a arquitetura N-Tier foi muito boa a uns anos atras onde eu estava começando com .net e web mas hoje acho um tiro no pé.

Sobre os livros, tenho lido a literatura basica: Codigo Limpo, Codificador Limpo do Robert Martin, Test Driven Development do Kent Beck, Domain Driven Design do Eric Evans, e mais alguns.

Abraços e obrigado a todos ;)

________________________
Otavio Costa
otavi...@gmail.com

[Marcos Pita]

Na minha opinião a arquitetura N-Tier não é um tiro no pé, muito pelo contrário, só que na minha opinião o conceito de tier está um pouco mudado, eu começo a pensar em tier como blocos que podem ser alterados/substituidos sem afetar os demais tiers.

Se você estruturar bem seu sistema, entendendo que tudo vai estar/ser um tier, você pode substituir todo um tier sem afetar sua aplicação

[Otavio Costa]

Oi Marcos,

não sei se me expressei bem, pois Service, Domain, Repositorio, Infra.... também é um N-Tier. ;)

o que nao gosto é do modelo BLL, DAL, DTO...

Aqui, mesmo nessa arquitetura, temos interface em tudo e instanciamos atraver de um factory com um xml de configuracao. Podemos substituir um tier desse sem problemas. Ate conseguimos fazer uma injeção de dependencia.

O meu maior problema é que a BLL acaba nao tendo toda a regra de negocio como deveria ser (to falando na minha pratica ;) ) dependendo dos DTO´s pra verificacao. Pra mockar tudo fica impraticavel.

[]´s

________________________
Otavio Costa
otavi...@gmail.com

[Gustavo Cruz]

@Marcos,

É bem por aí.

Eu atualmente utilizo a famosa arquitetura "Cebola", focada em aplicações dirigidas a domínio, mas é claro, isso varia de projeto para projeto.

Para quem quiser estudar:

http://jeffreypalermo.com/blog/the-onion-architecture-part-1/