I never understood why ppl need to wrap NH session or NH whatever. My app can know only my repository interfaces and that is all. The management of Session/ObjectContext is *not* a matter of the app. itself. The management of Session/ObjectContext should be implemented through AOP (actionfilter, webmodule, wcfbehavior, dynamicproxy, staticproxy); as you can inject a different implementation of Repository you can inject a different impl. of the aspect.
With good ORMs you will end having: one repository impl. for single-entity-CRUD, many EQOs, and AOP for persistence-context. On Tue, Jul 13, 2010 at 12:35 AM, Vadim Chekan <[email protected]>wrote: > On Jul 12, 5:30 am, Fabio Maulo <[email protected]> wrote: > > If an ORM can't work with my POCOs it is not a choice for my needs. > > For some reason EF4 was improved... well at least they are trying to give > > support to POCO ;) > > EF improvements is one of the problems actually :) > > Fundamental problem is that you will build not "super" ORM but "sub" > orm :) > You can include only features which present in all ORM. And the more > ORM you plan to use, the smaller set of features you can have. For > example, you can work only with POCO objects as common denominator. It > limits your choice of ORM and architectural patterns right off the > bat, and it is just a beginning. As Fred noted, differences in > transactions, sessions and other "small details" will effectively > leave you without those features. > > When new EF (or NH) comes out, you have review your wrapper to include > new features. If you don't, you'll have difficult times explaining to > your programmers why you force them to use old crap which tax their > code quality and development time. > So "abstract" framework becomes a moving target (antipattern). > > If after your wrapper is done, you decided to add say Subsonic, which > is a simpler ORM, you won't be able to do it, because chances are > subsonic will lack some features which already are part of the wrapper > contract. > > You can build a wrapper for particular use case though. The project > requirements must be well known ahead and requirements for persistence > system must be relatively simple because you won't have any freedom in > optimization your code for particular ORM. > But in as generic sense as in initial question this solution never > will be complete and will cause 10x more problems then it solves. > > Vadim. > > > > > > > On Mon, Jul 12, 2010 at 9:12 AM, <[email protected]> wrote: > > > And what are the benefits ? > > > > > You say NHIbernate is just an option and that is not true. There are > design > > > choices and NHibernate is very different from EF by design. Choosing to > use > > > an > > > ORM and a tool like NHibernate is not a choice that should be taken > lightly > > > ! > > > And even then, each solutions is providing it own implementation of > the > > > subject. Ok it looks easy with NHibernate, since you are using Poco. > But > > > not all > > > ORM. It is not because you have an interface defining what object and > what > > > query you can access and a Poco library containing your entities that > all > > > ORM > > > framework can be used. They all handle differently track changing, > session > > > mgmt, > > > mapping attributes, inheritance...So will you spend 2 months trying to > > > build the > > > "superORM Abstraction Toolkit" (And even you can't guarantee that it > will > > > work > > > with a predictible amount of work), or will you focus on testability > and > > > simplicity ? > > > > > That's exactly JPA. So here are the specifications. > > > > > I understand what you say, but I'm not using a DAO impl for changing > the > > > components, I'm using it for testability. > > > > > What you describe is different. You know the product you are using. You > > > face new > > > issues or requirements, you handle them. Ok. But that's something you > must > > > think > > > of before coding. That's not because you are using an ORM that you > won't > > > need a > > > plain old sql connection to get closer to the metal. > > > > > Fred. > > > > > Selon Fabio Maulo <[email protected]>: > > > > > > Can you provide an example about "messy codebase" ? > > > > I'm using Repository/DAOs and EQO. > > > > CpBT was born using ADO.NET and then, only changing DAOs > > > implementations, > > > > using NHibernate. > > > > In a winAzure app. we have a usecase that was born with a > service-class > > > > using various EQO to return a pretty complex ViewModel, then I have > > > injected > > > > another impl. using BlobStorage. > > > > > > NHibernate is only an option, NHibernate.Validator, Windsor and so on > are > > > > "only" options. > > > > > > In prjs, where I'm working, only the implementation of DAO/Repository > + > > > EQO > > > > knows about NHibernate. > > > > > > On Mon, Jul 12, 2010 at 6:52 AM, <[email protected]> wrote: > > > > > > > If you choose a product (g.e NHibernate) and put a new level of > > > abstraction > > > > > on > > > > > it, the only result will be a messy codebase and (pardon me) a true > > > waste > > > > > of > > > > > time. > > > > > > > If you think one day you will have to change your Data Layer then : > > > > > - You didn't pick the right choice > > > > > - Your selection process is not sufficient > > > > > - You will lose time doing technical staff that give very little > added > > > > > value to > > > > > your developpement. > > > > > - You will face performance issues (the house that jack built > syndrom) > > > > > > > There is no such thinh as the ultimate reusable component because > it is > > > by > > > > > design a bad idea. > > > > > > > In the Java world, it is called JDO,JPA and EJB. Just take a tour, > take > > > a > > > > > look, > > > > > try to make your path through the 23 different frameworks required > and > > > the > > > > > maount of work required to simply do some very basic CRUD stuff and > you > > > > > will get > > > > > a flavor of the subject. > > > > > > > Putting a "level of abstraction" is never a good thing when > building > > > the > > > > > basements. It is just increasing the complexity while putting some > real > > > > > risk. > > > > > > > If you can't explain why and how you choose your persistence layer, > > > then > > > > > that's > > > > > where your real risk is. And it won't go away by saying "I can > change > > > if I > > > > > need > > > > > to". > > > > > > > Sorry, > > > > > > > Fred. > > > > > > > Selon deepucodemaker <[email protected]>: > > > > > > > > Hello All, > > > > > > > > I would like to design a system/application using NHibernate. But > I > > > > > > also want to so flexible that in future if I unplug the > NHibernate > > > and > > > > > > use ADO.NET Entity framework or other framework application > should > > > not > > > > > > crash. > > > > > > > > Can someone please send me links/videos so that i can design > > > > > > independent architecture for this purpose. > > > > > > > > I tried lot in google and understood NHibernate but there is no > > > > > > example which helps me to deisgn ultimate reusable component. > > > > > > > > Please do the needful > > > > > > > > Thanks > > > > > > > > -- > > > > > > 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]> > > > > > <nhusers%[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]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > <nhusers%[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. > > > > > > -- > > > > 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]<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]> > <nhusers%[email protected]<nhusers%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/nhusers?hl=en. > > > > -- > > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- 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.
