Hi Paul, Thanks for your quick reply. I do know and use DI containers, and I realize it sounds very much the same, the real difference is that I do not want to actually create an implementation of the interfaces, just to make NHibernate happy, I want NHibernate to create these implementations it self.
The reason I asked here is because of the AutoMapper and just the Fluent Mapping abilities this project offers, I would like this to also be able to automatically create mappings based on an interface structure, I was not aware of the fact that you can already do this using Fluent NHibernate, perhaps it is only NHibernate that I have to look at then? As of now the added complexity is in the way NHibernate creates its entities, and not so match in me wrapping the entities in interfaces, as I see it now. So if I would be able to solve the NHibernate issue (not really an issue) then in my future projects it would not be added complexity at all any more. Especially at least during development I don't even have to supply an implementation of the interface. The main end goal is to make developing an application using NHibernate even more painless then you guys have already done, and I realize that I could just create actual entities using auto properties, but I have very strong (perhaps un-realistic) feelings about using interfaces to make change more easy, "Who am I to decide nothing will change"? An other thing that guarantee this approach gives is that my data objects will always remain dumb, no body will actually add logic to it, at least not the implementations coming from NHibernate. I hope I was more able to explain what I like to achieve :) -Mark On Dec 3, 5:23 am, "Paul Batum" <[EMAIL PROTECTED]> wrote: > Hi Mark, > > I would like to suggest that you learn about using dependency injection (DI) > frameworks. It sounds like you are basically describing one without > realising it here: "Then finally I want some factory that will create new > objects depending on the requested interface, exactly like a mocking > framework would do it". My DI framework of choice is > StructureMap<http://structuremap.sourceforge.net>, > but there are > many<http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersI...>to > choose from. > > You may be interested to read this very recent > post<http://fabiomaulo.blogspot.com/2008/11/entities-behavior-injection.html>by > the NHibernate lead Fabio Maulo. He demonstrates using DI to manage > entities by leveraging some NHibernate hooks. > > To be honest, I am struggling to understand how you see Fluent NHibernate > fitting into your plan. How would your approach to MAPPING your entities > differ? Yes, all your relationships would be described in terms of > interfaces rather than concrete types, but this is already possible (to the > best of my knowledge). > > Finally, I would like to offer a small caution. I would have you ask > yourself what you are actually gaining by trying to wrap all your entities > in interfaces. I can appreciate the appeal from a purity standpoint, but in > my opinion the added complexity must be justifiable with some concrete > benefits. > > Good luck with your investigation. > > Paul Batum > > On Wed, Dec 3, 2008 at 11:44 AM, <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I have been using your Fluent NHibernate libraries now only for a very > > short time and I think it is great and I have an idea that I would > > like to explore. > > > I would like to be able to define my object structure using interfaces > > only, then have the mappings be resolved accordingly to the interfaces > > relations. Then finally I want some factory that will create new > > objects depending on the requested interface, exactly like a mocking > > framework would do it, whenever NHibernate needs to provide me with a > > new entity. I would also need a way to do this manually like > > Repository.Give<T>() (or what ever) so that I can request a new > > instance that implements my interface. > > > The reason for this is that I want my entities to be dumb, and I want > > to be able to use interfaces and also maintain the references using > > only interfaces. Now with these two wishes there is really no use for > > creating actual implementations of these objects. I can see there is a > > performance hit by using this scenario so for an production > > environment I would probably want to have the actual implementations > > created, but I would still like to only use interfaces in all my other > > code. > > > Especially during development iterations I think this can be useful > > and depending on performance it might be useful for more, but I don't > > know that. > > > So my question is: What do you guys think of this? I am very happy > > exploring this by my self and contributing back if indeed it is > > useful, but I like some small pointers as I am still new to NHibernate > > and I don't seem too figure out what I have to do to have NHibernate > > mock entities (maybe also because it is getting very late). I Found > > IProxyFactoryFactory but I am no sure if that is the place to be. > > > Any feedback is appreciated. > > > -Mark > > [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" 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/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
