Multiple ORM in single application : Design Required
deepucodemaker
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
f....@free.fr
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 <dee...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To post to this group, send email to nhu...@googlegroups.com.
> To unsubscribe from this group, send email to
> nhusers+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nhusers?hl=en.
>
>
Oskar Berggren
But don't sprinkle your entire codebase with nhibernate references either.
The domain model and major business logic should be as independent as
possible of external dependencies.
One might use the repository pattern, with the repository
implementation in a separate assembly, that do have direct use of
nhibernate.
Then of course, there may be nhibernate-isms "leaking" through, even
when you don't have direct usage of the API.
/Oskar
2010/7/12 <f....@free.fr>:
Fabio Maulo
Fabio Maulo
Fabio Maulo
Then of course, there may be nhibernate-isms "leaking" through, even
when you don't have direct usage of the API.
Fabio Maulo
f....@free.fr
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 <fabio...@gmail.com>:
> 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.
>
> nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> > .
> > > 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 nhu...@googlegroups.com.
> > To unsubscribe from this group, send email to
> >
> nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> > http://groups.google.com/group/nhusers?hl=en.
> >
> >
>
>
> --
> Fabio Maulo
>
Oskar Berggren
No, not a list of "issues". I was more referring to the potential risk
and that you expect a certain behavior from your persistance. That is,
even if direct API use is limited, it doesn't mean you can replace it
with _anything_ else. You would probably still need something with a
fairly similar feature set. Of course, nothing strange with that.
(E.g. if you design with lazy load in mind, you might get bad
performance if you suddenly cannot use lazy.)
/Oskar
Fabio Maulo
--
Fabio Maulo
Fabio Maulo
--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
--
Fabio Maulo
f....@free.fr
I got tired of code generation-gui designed-wizard-but-use-T4-instead...
Selon Fabio Maulo <fabio...@gmail.com>:
> 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 ;)
>
<nhusers%2Bunsu...@googlegroups.com<nhusers%252Buns...@googlegroups.com>
> > >
> > > > .
> > > > > 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 nhu...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > >
> > >
> nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> >
>
<nhusers%2Bunsu...@googlegroups.com<nhusers%252Buns...@googlegroups.com>
Vadim Chekan
> 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 ;)
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.
> > > 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.
>
> > > > > 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 nhu...@googlegroups.com.
> > > > > To unsubscribe from this group, send email to
>
> > > nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> > > > .
> > > > > 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 nhu...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
>
> > > nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
Fabio Maulo
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
--
Fabio Maulo
f....@free.fr
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 <fabio...@gmail.com>:
> 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.
<nhusers%2Bunsu...@googlegroups.com<nhusers%252Buns...@googlegroups.com>
> >
>
<nhusers%252Buns...@googlegroups.com<nhusers%25252Bun...@googlegroups.com>
> > >
> > >
> > > > > > .
> > > > > > > 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 nhu...@googlegroups.com.
> > > > > > To unsubscribe from this group, send email to
> > >
> > > > >
> nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> >
>
<nhusers%2Bunsu...@googlegroups.com<nhusers%252Buns...@googlegroups.com>
> > >
> > > >
>
<nhusers%2Bunsu...@googlegroups.com<nhusers%252Buns...@googlegroups.com>
> >
>
<nhusers%252Buns...@googlegroups.com<nhusers%25252Bun...@googlegroups.com>
deepu
Thanks and Regards,
Deepak Rao
Ajai Shankar
Greg Young
On Thu, Jul 15, 2010 at 2:01 AM, Ajai Shankar <ajai.s...@gmail.com> wrote:
> just that UnitOfWork.Start() sounds so cool...
>
> On Wed, Jul 14, 2010 at 11:30 PM, deepu <dee...@gmail.com> wrote:
>>
>> Thanks all for great discussion.
>>
--
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention
Max André Bündchen
> single-entity-CRUD, many EQOs, and AOP for persistence-context.
Can you point some references about this (articles or something)? If a
NHibernate-related reference better!
Jason Dentler
--
Fabio Maulo
EQO is covered here:All of this is covered in NHibernate 3 Cookbook, due out later this year.
Fabio Maulo