@Fabio Thank you. This looks like this might point me in the right direction. Basically what I am after is getting NH to do the heavy lifting of transformation from one entity to another without resorting to projections to do a pull-push (etl?) transformation... I'd prefer to broadcast the propertyname/values to a listener that can do the transformation. Based on my first run thru your posts, it looks like I could write presentation model entities in the abstraction (using the powerful 'entity-name' ) from a collection of values . The only quandry right now is getting a flattened dictionary of values out of something like IInterceptor's OnSave...anything beyond primitive values (like components) requires some parsing to flatten out to a single dictionary.I am not sure it is worth it yet.
On Aug 12, 5:15 am, Fabio Maulo <[email protected]> wrote: > Are you describing these situations > ?http://fabiomaulo.blogspot.com/2008/10/less-than-few-is-gof.htmlhttp://fabiomaulo.blogspot.com/2008/10/less-than-gof-is-hbm.htmlhttp://fabiomaulo.blogspot.com/2009/07/duck-typing-with-nhibernate.html > <http://fabiomaulo.blogspot.com/2008/10/less-than-gof-is-hbm.html> > > 2009/8/12 Mike Nichols <[email protected]> > > > > > > > Hi Fabio > > I use Projections and such now with some transformers and this works. > > What I was considering though is simplifying the mapping between the > > write and read contexts and it seems like the interception methods' > > exposure of flattened properties in conjunction with a typed > > dictionary adapter would make it easier than maintaining hql/criteria > > property name/alias changes since they aren't so refactor friendly ( I > > know about the new criteria api ). > > So you'd have an mapping interface in your reporting context, > > ISomePresentationModelMap, and that gets hydrated by a dictionary > > adapter that receives the state[] and propertyNames[] > > collections...This is used to create/update the presentation model. > > Now the domain schema has less bearing on my presentation model at > > all, except for the property names interface which I'd expect to > > maintain anyways. > > Sorry for thinking out loud here...I was just seeing if any usage of > > interceptors for updating another model in this fashion has been > > explored before. > > > On Aug 11, 9:17 pm, Fabio Maulo <[email protected]> wrote: > > > For reports you can use > > > Report-queries asselect p.Name, p.Surname from Person > > > with an appropriate result transformer > > > > Map to View > > > There are some example on the cloud and in NH2.1.0 is even more easy > > using > > > schema-action > > > > Reporting services > > > > 2009/8/11 Mike Nichols <[email protected]> > > > > > I am looking into strategies for denormalizing my domain for > > > > reporting. > > > > Ideally, I persist a flattened out presentation model and, while i was > > > > looking at doing some asynch event handling of changes to domain state > > > > to do this, it seems like hooking into an NH interceptor could fire > > > > messages in some bus with the propertyname/state collections it > > > > already is providing and on the reporting context side use an > > > > DictionaryAdapter to transform those collections into a strongly typed > > > > mapping object in its anti-corruption layer. > > > > > My question is whether anyone has done something similar to this and > > > > what their experience was with it or holes in this idea that I should > > > > be wary of. > > > > -- > > > Fabio Maulo > > -- > Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
