Entity Framework, DTOs e Self-Tracking Entities
O último post do time do Entity Framework é bem interessante no contexto dos assuntos discutidos neste Arquitetura em Pauta nos últimos tempos.
Numa aplicação complexa e n-camadas, sabemos que nem sempre queremos passar os dados das nossas entidades conceituais para a camada de apresentação. O motivo é simples: por vezes precisamos apresentar menos dados do que a entidade contém (ex.: só nome e código, deixando os outros de lado); outras vezes queremos esconder do usuário campos para cálculos internos usados na camada de negócio.
A solução para isto tem sido o uso de DTO’s. Eles contêm a projeção mínima e necessária de um subconjunto dos dados das entidades conceituais e servem para levar e trazer dados entre a regra de negócio e a apresentação e/ou um serviço externo.
No entanto, usar um DTO é trabalhoso. Por exemplo, uma entidade conceitual pode exigir diferentes DTOs em contextos diferentes aumentando a complexidade devido ao grande número de DTOs exigidos. Pior: DTOs exigem uma boa carga de programação para marcarmos o que o usuário mudou e devolver ao Entity Framework para que este atualize o ObjectContext e o Banco de Dados.
Uma segunda solução seria usar as entidades conceituais como base para a transferência entre camadas. Neste caso aceitamos expor mais dados do que necessário visando ganhar simplicidade. Mas ainda falta o tracking do que foi editado, tornando difícil a atualização do ObjectContext e Banco de Dados.
O que o blog anuncia? Um novo tipo de objeto de transferência denominado “self-tracking entities”. Ele visa a simplicidade por dois caminhos: resolve o problema do tracking e não deixa a complexidade se espalhar devido às várias projeções comum em DTOs.
Queria pedir sua atenção em duas questões neste blog:
A) Notem como eles usam exemplos de uso destas entidades para testar o conceito. Se a programação for simples, é porque foi criada uma API/classe/framework simples (ver blog passado);
b) Notem também que estão abrindo mais uma opção de tipo de objeto de transferência no leque entre RAD e LCMD (ver blog).
- DTO’s são complexos, mas minimizam transferência de dados e protegem dados de serem modificados fora de contexto (a opção mais LCMD);
- A passagem de Entidades Conceituais (como acontece hoje no Entity Framework) simplifica o número de classes, mas não minimiza a transferência de dados, não protege dados de mudanças fora de contexto (como a atualização indevida de um atributo que não deveria ser exposto em um contexto de diálogo com o usuário), nem facilita a atualização do ObjectContext e Banco de Dados (intemediário entre LCMD e RAD);
- Self-tracking entities simplifica o número de classes e a programação para a atualização do Object Context e Banco de Dados. POrtanto, um mix de Entidade Conceitual com tracking (a opção mais RAD);
O que eu gostaria? DTOs + tracking!
Bom saber que posso mandar minha opinião para lá.
Abraços