you can cache projections with NH. I see it as a trade off. code
doesn't get much simpler than this
var entity = session.Get<Entity>(id);
var dto = Mapper.Map<Entity, Dto>(entity);
return View(dto);
the trade off is the number of database hits. this may or may not be a
problem. you could alter the query to pull the required graph back
var entity = session
.CreateQuery("from Entity e join fetch ... where e.id = :id")
.SetParameter("id", id)
.UniqueResult<Entity>();
var dto = Mapper.Map<Entity, Dto>(entity);
return View(dto);
retrieving the entity is slightly more complex, but we reduce the
number of database calls. we still have the mapping of domain to view
model. which can be solved with projections
var dto= session
.CreateQuery("select new Dto(...) from Entity e join fetch ...
where e.id = :id")
.SetParameter("id", id)
.UniqueResult<dto>();
return View(dto);
this makes the core more complex that before but we remove the need
for AutoMapper. in each instance there are trade-offs between
simplicity of code vs. performance. I don't jump straight to option
3, because I find the development gains of AutoMapper out weight the
performance hit required.
I am also very cautious of 2nd level cache. I treat it as a last
resort to performance improvements. 1st I ensure I have the least
number of remote calls, then I solve O^N operations, then I apply 2nd
level cache.
On Oct 5, 10:20 pm, Mark Olsen <[email protected]> wrote:
> Hello,
>
> In a project I'm working on, to populate the asp.net mvc views, we are
> loading NHibernate entities (through a repository interface) and then
> using Automapper to map to a viewmodel. So far, we have not
> implemented the 2nd level cache yet. I was wondering if I would see
> improved performance by using ICriteria and projections to create a
> sql query to directly populate the view model instead of going to the
> trouble of loading the entities. At first glance, this would
> definitely help performance because I would be only getting the exact
> data I need with a very specific query. However, the 2nd level cache
> has me wondering if implementing that would be a better way to go
> about things. I would imagine directly loading the view model
> wouldn't use the 2nd level cache because we aren't really loading the
> entities but this would mean going back to the database every time
> unless we implemented some sort of view model cache. Can anyone give
> me any insight?
>
> Mark
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
