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]> > > > > > . > > > > > 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. > > > -- > > 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.
