2 Removed reference to other answerer
source | link

I don't reallygenerally expose the DAL directly to the UI either.

Normally, I create model classes as close as the final UI representation as possible. And wrappers that translate / transform one or more entities from the DB into those.

This, as you said, might seem a little bit redundant, but it is useful when the viewmodel gets complex enough so that you have different representations for querying multiples objects vs updating / inserting / deleting those.

It is actually inspired on the CQRS design pattern, where different representations are used for queries (the new wrapped classes you were talking) and updates back from the viewmodel to the entities using commands.

Here is a very good link from Martin Fowler's blog explaining CQRS.

I actually use Web API 2 for the commands as the web applications are really client-side intensive (KnockoutJS etc).

I don't really expose the DAL directly to the UI either.

Normally, I create model classes as close as the final UI representation as possible. And wrappers that translate / transform one or more entities from the DB into those.

This, as you said, might seem a little bit redundant, but it is useful when the viewmodel gets complex enough so that you have different representations for querying multiples objects vs updating / inserting / deleting those.

It is actually inspired on the CQRS design pattern, where different representations are used for queries (the new wrapped classes you were talking) and updates back from the viewmodel to the entities using commands.

Here is a very good link from Martin Fowler's blog.

I actually use Web API 2 for the commands as the web applications are really client-side intensive (KnockoutJS etc).

I don't generally expose the DAL directly to the UI.

Normally, I create model classes as close as the final UI representation as possible. And wrappers that translate / transform one or more entities from the DB into those.

This, as you said, might seem a little bit redundant, but it is useful when the viewmodel gets complex enough so that you have different representations for querying multiples objects vs updating / inserting / deleting those.

It is actually inspired on the CQRS design pattern, where different representations are used for queries (the new wrapped classes you were talking) and updates back from the viewmodel to the entities using commands.

Here is a very good link from Martin Fowler's blog explaining CQRS.

I actually use Web API 2 for the commands as the web applications are really client-side intensive (KnockoutJS etc).

    Post Migrated Here from stackoverflow.com
1
source | link

I don't really expose the DAL directly to the UI either.

Normally, I create model classes as close as the final UI representation as possible. And wrappers that translate / transform one or more entities from the DB into those.

This, as you said, might seem a little bit redundant, but it is useful when the viewmodel gets complex enough so that you have different representations for querying multiples objects vs updating / inserting / deleting those.

It is actually inspired on the CQRS design pattern, where different representations are used for queries (the new wrapped classes you were talking) and updates back from the viewmodel to the entities using commands.

Here is a very good link from Martin Fowler's blog.

I actually use Web API 2 for the commands as the web applications are really client-side intensive (KnockoutJS etc).