what do you mean by "work out"? It is very likely that your application will work, but i would advice you against using a detached criteria or any NHibernate object out side the boundries of your data access layer. If you're working a 2-tier application, where your service layer is actually you're DAL then its seems fine.
just remember that you use NHibernate for persistance, and that you're DAL must encapsulate as much as it can any framework\technology that is used for persistency (even the very fact that you're using a relational db for persisting your domain) On Sun, Aug 29, 2010 at 8:38 PM, rhartzog <[email protected]> wrote: > Thank you Diego, yes let me clarify. When I say repository in this > example, I am referencing where my repository would have been in my > previous approach, now I wouldn't call it that. > > I am just curious if anyone has tried and it didn't work out well, or > if it did, etc. Just more curiosity, than anything else. > > On Aug 29, 12:17 pm, Diego Mijelshon <[email protected]> wrote: > > I'd say if the Repository returns DetachedCriterias, it's not a > repository > > at all, and the dual-role of the service layer (doing the actual > retrieval > > and mapping to VM's, although that's delegated) is debatable. > > But if it works for you, it's testable enough and easy to work with, none > of > > our opinions should make a difference :-) > > > > Diego > > > > > > > > On Sun, Aug 29, 2010 at 14:03, rhartzog <[email protected]> wrote: > > > I have started playing with something different from my normal > > > repositories where I have each method from repository return > > > DetachedCriteria that I can then execute on in a service layer. The > > > service layer wires up the view models for screen consumption. Very > > > simple example: > > > > > Employee Domain Object: > > > FirstName, > > > LastName, > > > List<Addresses> > > > > > Employee View Model > > > FirstName, > > > LastName > > > > > Employee Repository: > > > public DetachedCriteria GetAll() > > > > > Employee Service; > > > using sess & tx > > > var query= > > > GetAll().ExecutableCriteria(sess).Future<Employee>(); > > > > > var otherQuery = more queries here, maybe for Employee > > > addresses or departments, etc. > > > > > Mapper.Map<List<Employee>, List<EmployeeVM>>(emps); > > > > > This is because sometimes the VM needs more than one entitiy and I can > > > use multiple detached criteria to formulate the least amount of calls > > > to the database using session in the service layer. Am I creating > > > more of a headache? Good? Bad? Ugly? Any suggestions would be > > > appreciated. > > > > > -- > > > 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]<nhusers%[email protected]> > <nhusers%[email protected]<nhusers%[email protected]>> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/nhusers?hl=en. > > -- > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- 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.
