"I never understood why ppl need to wrap NH session or NH whatever"
I would even say : Why a UoW when you can open a session ?
Here is my DAO :
/// <summary>
/// Facade to provide a clean interface
/// </summary>
public interface IRepositoryFactory
{
IDbConnection ObtainsRawSql();
IStateLessRepository ObtainsStateLess();
IStateFullRepository ObtainsStateFull();
}
/// <summary>
/// Standardised interface of repository, implementing IDisposable
/// </summary>
public interface IBaseRepository:IDisposable
{
void Save(object entity);
void Update(object entity);
void Delete(object entity);
T Get<T>(object key);
IList<T> AllEntities<T>();
}
/// <summary>
/// Implements a statefull version
/// </summary>
public interface IStateFullRepository : IBaseRepository
{
void AcknowledgeChanges();
IQueryable<T> Linq<T>();
void Reset();
}
/// <summary>
/// Implements a stateless version
/// </summary>
public interface IStateLessRepository : IBaseRepository
{
}
Simple and working just fine.
Using AOP to create transaction if required, and a couple of rules at the dev
rule level for effective mapping strategy.
Fred.
Selon Fabio Maulo <[email protected]>:
> 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.
>
>
--
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.
