Finally which ORM tool?

[AliRezaGoogle]

Hi
Currently there are some good ORM tools like NHibernate and LLBGL.
Microsoft is working on it's own one ( I think it's name is
EntitySpace) but not released yet.
I want to know members idea about selecting one of these ORMs:

--Should we wait untill Microsoft release his own ORM? ( and maybe
after two or three years again releases another one and we have to
throw our experiences away and styart to learn new one?)
--Choosing current ORMs is nice? (Does for example NHibernate remain
with .NET forever with support? What about future release of .NET? Is
there any quaranty that future features of .NET remain compatible with
current ORM frameworks? )

Regards

 

[Jon Skeet [C# MVP]]

Currently there are some good ORM tools like NHibernate and LLBGL.
Microsoft is working on it's own one ( I think it's name is
EntitySpace) but not released yet.
I want to know members idea about selecting one of these ORMs:

--Should we wait untill Microsoft release his own ORM? ( and maybe
after two or three years again releases another one and we have to
throw our experiences away and styart to learn new one?)
--Choosing current ORMs is nice? (Does for example NHibernate remain
with .NET forever with support? What about future release of .NET? Is
there any quaranty that future features of .NET remain compatible with
current ORM frameworks? )

Well, firstly I have no experience of LLBGL, so can't talk about that.
NHibernate appeals to me due to it being open source, and I have had
very positive experiences of its Java cousin.

As for Microsoft: LINQ to SQL will be released with .NET 3.5, but that
only works with SQL Server and isn't as flexible as it might be. It's
good for rapid development, but I suspect that most serious projects
will wait until ADO.NET 3 is released with SQL Server 2008, and with
it LINQ to Entities.

Whichever you choose, don't underestimate the importance of LINQ. Even
if you don't plan to use C# 3 yet, you're likely to in the future, and
LINQ is *lovely* where you can use it. (In some cases you may have a
query which can't be expressed in LINQ, but that's okay.)

As for backward compatibility: I wouldn't expect MS to release a
version of .NET which breaks NHibernate or other libraries, and if it
*does* I'm sure the NHibernate community will rally round to make the
necessary changes.

Jon

 

[Wiktor Zychla [C# MVP]]

Currently there are some good ORM tools like NHibernate and LLBGL.

Microsoft is working on it's own one ( I think it's name is
EntitySpace) but not released yet.
I want to know members idea about selecting one of these ORMs:

currently we migrate our applications to devexpress xpo. after some heavy
research I find it most advanced and reliable of all orm frameworks known to
me.

among many typical orm features, xpo is capable of creating the database
structure on-the-fly (which means that you do not need any tables in your
database and even then you still can persist objects).

one of the most interesting features xpo provides is a unique three-tier
provider which stores the data using a simple webservice which is resposible
for storing the data in the database. the client application thinks it
stores the data in the database while in fact it talks to the application
server and the actual database is not directly exposed to the client
application. what's even more intersting - transactions are correctly
handled in such three-tier scenario which I belive is something really
unique.

regards,
Wiktor Zychla

 

[Guest]

That kind of question is more likely to get a number of individual, highly
subjective responses most of which revolve around the fact that the responder
either is an author of a particular offering, or is so wrapped up in the one
they use that they think there is no other.

You could look at the Repository Factory, a GAT package which comes from MS
Patterns and Practices, and which is now up on codeplex.com.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[Wiktor Zychla [C# MVP]]

subjective responses most of which revolve around the fact that the

responder
either is an author of a particular offering, or is so wrapped up in the
one
they use that they think there is no other.

.... or tried several different frameworks that is fairly sure of his/her
choice.

You could look at the Repository Factory, a GAT package which comes from
MS
Patterns and Practices, and which is now up on codeplex.com.

isn't that subjective, too?



Regards,
Wiktor Zychla

 

[Frans Bouma [C# MVP]]

currently we migrate our applications to devexpress xpo. after some
heavy research I find it most advanced and reliable of all orm
frameworks known to me.

Do you want to elaborate a bit why you didn't like LLBLGen Pro for
example? (If you've researched it of course). If you want you can mail
me directly. We're always looking into improving our work so if you
have some feedback for us, it would be awesome, thanks in advance for
your time!

FB


--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Wiktor Zychla [C# MVP]]

Do you want to elaborate a bit why you didn't like LLBLGen Pro for

example? (If you've researched it of course). If you want you can mail
me directly. We're always looking into improving our work so if you
have some feedback for us, it would be awesome, thanks in advance for
your time!

Frans,

although I did not spend much time with LLBLGen, I remember it as one of
"persistance aware" (or heavy weight) frameworks in a Fowler sense by which
I mean the dependence on automatically generated classes containing a lot of
code required by the mapping engine. xpo is much more "light weight" because
you can persist your objects with almost no additional requirements from
your business objects.

I do not think that the amount of support you need to put into your business
objects has any influence on the framework productivity (and thus I do not
dislike llblgen) but as a purist I prefer these light weight frameworks
(built on "persistance ignorance" paradigm). once I've spent 4 months on
developing such heavyweight framework for internal purposes and while it is
succesfully used in several applications, I do not think I am completely
happy with such approach.

Just for my curiosity - do you support the three-layer engine in which the
data is transmitted to the application server (while the application thinks
it talks to the database server) and the actual database server is hidden
behind the application server? I've just looked at the webpage and didn't
find any explicit reference to such feature. if yes, how you deal with
transactions in such scenario?

Regards,
Wiktor Zychla

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

one of the most interesting features xpo provides is a unique three-tier
provider which stores the data using a simple webservice which is
resposible for storing the data in the database. the client application
thinks it stores the data in the database while in fact it talks to the
application server and the actual database is not directly exposed to
the client application. what's even more intersting - transactions are
correctly handled in such three-tier scenario which I belive is
something really unique.

I thought DAL exposed as web service was an anti-pattern ?

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Currently there are some good ORM tools like NHibernate and LLBGL.
Microsoft is working on it's own one ( I think it's name is
EntitySpace) but not released yet.
I want to know members idea about selecting one of these ORMs:

--Should we wait untill Microsoft release his own ORM? ( and maybe
after two or three years again releases another one and we have to
throw our experiences away and styart to learn new one?)
--Choosing current ORMs is nice? (Does for example NHibernate remain
with .NET forever with support? What about future release of .NET? Is
there any quaranty that future features of .NET remain compatible with
current ORM frameworks? )

I would go for a well-known and respected framework like NHibernate
or LLBLGen.

There may be some consolidation in ORM frameworks, but those two
are very likely to survive.

Lots of users => they will be maintained for future .NET versions.

Arne

 

[Frans Bouma [C# MVP]]

Frans,

although I did not spend much time with LLBLGen, I remember it as one
of "persistance aware" (or heavy weight) frameworks in a Fowler sense
by which I mean the dependence on automatically generated classes
containing a lot of code required by the mapping engine. xpo is much
more "light weight" because you can persist your objects with almost
no additional requirements from your business objects.

that's indeed true, we're not a POCO framework. The idea behind that
is that in the end, you'll end up with entity classes which are rich
with code we already provide for you, so leaving it out in the first
place will not gain you anything in the end (in general). Also do we
assume that the abstract entity model is used to create a relational
model first, which is then reverse engineered to an abstract entity
model in our designer. Poco frameworks tend to project (the relational
model is a projection of the abstract entity model onto a relational
database) the abstract entity model onto classes which are then reverse
engineered towards a relational database if it doesn't exist. It's
basicly the same thing: you end up with 2 projections of the same
abstract entity model: one in the database and one in the classes and a
mapping in between to make sure both represent the same thing

I do not think that the amount of support you need to put into your
business objects has any influence on the framework productivity (and
thus I do not dislike llblgen) but as a purist I prefer these light
weight frameworks (built on "persistance ignorance" paradigm). once
I've spent 4 months on developing such heavyweight framework for
internal purposes and while it is succesfully used in several
applications, I do not think I am completely happy with such approach.

Sure, if you're more pleased with a POCO style approach, you should
pick that. After all: you should pick the tools which match your way of
thinking and way of working. For example this also means that if people
want to think in tables, SQL and sets of data, an o/r mapper in general
will be a rough ride.

Just for my curiosity - do you support the three-layer engine in
which the data is transmitted to the application server (while the
application thinks it talks to the database server) and the actual
database server is hidden behind the application server? I've just
looked at the webpage and didn't find any explicit reference to such
feature. if yes, how you deal with transactions in such scenario?

We don't provide such a feature because it wouldn't be that useful for
normal SOA oriented development anyway: services in general aren't used
as a tier, but as a separate vertical application stack, so you send
messages to it and it returns with the results. Therefore we simply
support webservices (through compact XML) and remoting (through a
custom very fast and compact binary formatter) and if the developer
needs a service on top of that, e.g. transactions, s/he can use the
WS-E* extensions to perform transactions over webservices, though in
general it's best practise to see services as separate applications you
communicate with because they fulfill a task for you, instead of seeing
them as a tier.

The downside of having a service as a tier in your application is that
it's a serious bottleneck in your application: it's not really scalable
as network overhead, serialization/deserialization etc. can really hurt
the performance and scalability of the application, something which is
solved by the message-based approach of soa services.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[James Crosswell]

Hi
Currently there are some good ORM tools like NHibernate and LLBGL.
Microsoft is working on it's own one ( I think it's name is
EntitySpace) but not released yet.
I want to know members idea about selecting one of these ORMs:

--Should we wait untill Microsoft release his own ORM? ( and maybe
after two or three years again releases another one and we have to
throw our experiences away and styart to learn new one?)
--Choosing current ORMs is nice? (Does for example NHibernate remain
with .NET forever with support? What about future release of .NET? Is
there any quaranty that future features of .NET remain compatible with
current ORM frameworks? )

I'm almost universally not happy with any of them to be honest... but
that's because I'm developing WCF web services and the only framework
that I've tried so far, which is built with n-tier in mind, was netTiers
- which I don't like because it's a code generation framework (meaning
it builds all your business objects for you and then rebuilds these
every time you make a changes to the databases... implying you can't
modify your business classes to support IMyInterface or anything like
that, making polymorphism often very difficult to use).

Otherwise I've used both DevExpress XPO and nHibernate. XPO is much
slicker in terms of generating and maintaining the underlying databases
and also has much better multi database support than nHibernate (which
chokes when doing simple stuff like using Guid fields with MS Access).
XPO also has a much more logical Attribute design since the nHibernate
attributes are basically a hack wrapper around an XML mapping document
(in fact, the attributes in nHibernate are simply used to generate an
XML document on the fly in memory, which is then used to generate the
object map). In XPO, as a consequence, you generally have to use far
fewer attributes (sometimes none, on a persistent class, other times
just one - for the class itself) and you don't have to worry about work
arounds to the inherently hacky nature of the attributes in nHibernate
(such as the fact that you have to give each attribute an "Order"
parameter to specify the order in which it should be processed -
attributes shouldn't have an order... they're meta data not logic).

Either of the above frameworks (nHibernate and XPO) are pretty good all
in all. But neither of them do n-tier at all well. Both of them depend
on the idea of "Sessions" and presume that you've got long lived
sessions that last the lifetime of the application and REQUIRE you to
save an object using the same session that it was loaded in (something
that will almost never be the case when doing n-tier). They also both
pretty much depend on the concept of lazy loading in order to decide
what needs to be loaded and what doesn't... something that doesn't work
at all when you're doing n-tier since the object and everything you need
to know about it needs to be streamed across to the client and the
session closed BEFORE you know what properties of the object the client
is interested in. Finally, both nHibernate and XPO require you define
the relationships between different classes if you want to create
queries joining those classes and ONLY let you join those classes in
your queries using the relationships that you defined using foreign
keys... so no ad-hoc query joins (not without resorting to writing your
own Views in the underlying database engine that you're using and
mapping these to a persistent nHibernate/XPO class).

All in all the move to an ORM has been a bit of a mixed blessing for me
in n-tier. I can see for plain vanilla desktop applications that none of
the above would really be issues and both of the above frameworks would
be huge time savers, but in n-tier you're going to spend about a month
working around their various issues before either of them are usable.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

 

[Wiktor Zychla [C# MVP]]

I thought DAL exposed as web service was an anti-pattern ?
yes but only if you consider webservices as a part of a soa. and not every
single web service application must be a soa.

Wiktor Zychla

 

[Wiktor Zychla [C# MVP]]

The downside of having a service as a tier in your application is that

it's a serious bottleneck in your application: it's not really scalable
as network overhead, serialization/deserialization etc. can really hurt
the performance and scalability of the application, something which is
solved by the message-based approach of soa services.

what I think is that no matter on how you talk to the service, the amount of
data you have to pass to it and retrieve from it depends on the business
logic involved on the client vs server side. in this sense moving all the
logic to the client (in "service as tier" approach) just solves one of your
problems (less work to do on the server) while not necessarily making more
data floating between client and the server - ultimately you often need to
present the data to the client so you have to transmit every single record
no matter which approach you prefer.

to me the message-based soa is exactly like the stored procedure interface
exposed by the database server to a lan application. it is sometimes
preferred over the direct sql speaking applications but there are no general
rules.

the "service as tier" is just much more lightweight and agile to me. i like
such approach in middle-scale but not too mission critical important
distributed applications. just on the other side I see the "everything on
the server" architecture (server-side ajax) which is the ultimate tool for
fighting with the worst nightmare of any mixed architecture (including
message-based soa and asp.net) - cross site request forgery threat (which
you can only fight by providing tedious double and triple validations on the
server side).

I just like then to see the boundaries : service as a tier on the left (most
agile but risky) and server-side ajax on the right (completely safe but
difficult). anything between is just a choice of prorities.

Regards,
Wiktor Zychla

 

[PhilipDaniels]

I'm almost universally not happy with any of them to be honest... but
that's because I'm developing WCF web services and the only framework
that I've tried so far, which is built with n-tier in mind, was netTiers
- which I don't like because it's a code generation framework (meaning
it builds all your business objects for you and then rebuilds these
every time you make a changes to the databases... implying you can't
modify your business classes to support IMyInterface or anything like
that, making polymorphism often very difficult to use).

James, when did you look at NetTiers? The current version, for an
entity Job, will generate a class "public class Job : JobBase" which
is basically an empty file in which you could add your interface. Once
generated, this file is never overwritten.

The guts of the generated object will be in a class called JobBase in
the file JobBase.generated.cs which *will* get overwritten at every
regeneration.

This scheme does have some disadvantages, I find it a bit of a pain in
the debugger - you have to always drill down to the base class - but
the example you cite isn't one of them. I think I would prefer it if
they used partial classes instead, but that is a fairly simple
template hack.

 

[James Crosswell]

James, when did you look at NetTiers? The current version, for an
entity Job, will generate a class "public class Job : JobBase" which
is basically an empty file in which you could add your interface. Once
generated, this file is never overwritten.

Hey Philip,

Thanks, I see... although presumably if it never gets overwritten then
it doesn't contain any of the fields/properties that map to anything
stored in the databases, so any interfaces implemented by this class, by
implication, have nothing to do with your persistent data, unless
perhaps you declared a bunch of abstract members in this class for any
data properties/fields that your interface required.

I also had issues with the class generation not working unless I deleted
the entire directory/project that NetTiers was generating for me (it did
some freaky caching stuff that broke things - maybe certain files
similar to these base files that weren't getting overwritten and needed
to be to effect the changes that I'd made to the databases).

Generally speaking I don't much care for code generation frameworks
though, even if there was away of working around the above. Even doing
basic stuff (like changing the build directory for the NetTier generated
projects) required I learn a whole new branch of arcane knowlege about
CodeSmith and how their templates work, how to add properties to them
etc. - not really stuff that draws on my existing C# knowledge. Where
possible I'd rather go with tools that let me leverage my existing
knowledge.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

 

[Frans Bouma [C# MVP]]

I'm almost universally not happy with any of them to be honest... but
that's because I'm developing WCF web services and the only framework
that I've tried so far, which is built with n-tier in mind, was
netTiers - which I don't like because it's a code generation
framework (meaning it builds all your business objects for you and
then rebuilds these every time you make a changes to the databases...
implying you can't modify your business classes to support
IMyInterface or anything like that, making polymorphism often very
difficult to use).

Try ours: LLBLGen Pro (sorry for the sales pitch ). It's suitable
for WCF out of the box: change tracking is done inside the entities,
not in some context / session so no attach/detach hell, compact XML
(change tracking info is only a small element) and if you want to use
remoting, very compact and fast binary serialization/deserialization
(using own serialization stack for entities, much faster and way more
compact than binaryformatter can). We use 'adapters' so you can simply
persist entities to the database represented by an adapter. (we also
support the model where an entity has a save method for example, we
call that SelfServicing). LLBLGen Pro has advanced eager-loading
capabilities so you can fetch graphs in 1 statement, where the runtime
picks the most efficient way to fetch the graph for you.

The entities aren't POCO, but the code generator is very flexible and
partial classes allow you to add code to the entity classes without
problems.

Personally I think if you want a POCO framework and a lot of features
in the entities, you'll end up with either post-compile code generation
(== you can't see what's generated, you can't control it with template
changes, additional templates etc.) or at runtime subclassing, which
has its own set of drawbacks.

Either of the above frameworks (nHibernate and XPO) are pretty good
all in all. But neither of them do n-tier at all well. Both of them
depend on the idea of "Sessions" and presume that you've got long
lived sessions that last the lifetime of the application and REQUIRE
you to save an object using the same session that it was loaded in
(something that will almost never be the case when doing n-tier).
They also both pretty much depend on the concept of lazy loading in
order to decide what needs to be loaded and what doesn't... something
that doesn't work at all when you're doing n-tier since the object
and everything you need to know about it needs to be streamed across
to the client and the session closed BEFORE you know what properties
of the object the client is interested in. Finally, both nHibernate
and XPO require you define the relationships between different
classes if you want to create queries joining those classes and ONLY
let you join those classes in your queries using the relationships
that you defined using foreign keys... so no ad-hoc query joins (not
without resorting to writing your own Views in the underlying
database engine that you're using and mapping these to a persistent
nHibernate/XPO class).

I think in general it's not that common to define ad-hoc joins.
LLBLGen Pro can do it though, you can define an EntityRelation in code
which is usable for joins (or you can define a subquery predicate if
you want) if you want to define a join between entities which don't
have a relation (LLBLGen pro finds the relations between entities by
itself, you can add new ones if you want to)

All in all the move to an ORM has been a bit of a mixed blessing for
me in n-tier. I can see for plain vanilla desktop applications that
none of the above would really be issues and both of the above
frameworks would be huge time savers, but in n-tier you're going to
spend about a month working around their various issues before either
of them are usable.

I think the central context/session design which is common among most
O/R mappers is the cause of many of these problems, and which is also
why we didn't use this pattern in LLBLGen Pro. Linq to Sql / Entities
both have the same attach/detach hell btw.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Frans Bouma [C# MVP]]

yes but only if you consider webservices as a part of a soa. and not
every single web service application must be a soa.

Though in THAT case, a webservice is the most slowest way to implement
a tier in an n-tier application, as it doesn't scale that well in that
way due to the chattyness of tier communication and the slowness of
serialization/deserialization. (try to pull 100,000 entities over the
wire to process them on the client, while you could have done the
processing on the server)

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Jon Skeet [C# MVP]]

On Oct 11, 9:06 am, "Frans Bouma [C# MVP]"

I think the central context/session design which is common among most
O/R mappers is the cause of many of these problems, and which is also
why we didn't use this pattern in LLBLGen Pro. Linq to Sql / Entities
both have the same attach/detach hell btw.

Without a context/session design, how do you ensure identity
management though?
Just curious. I must actually look at LLBLGen Pro some time...

Jon

 

[James Crosswell]

Without a context/session design, how do you ensure identity
management though?

Maybe I'm not understanding what you mean by identity management but I
use Guid fields for all my Object Ids so I don't have any "management"
issues. Guid's get created for new objects, on the client, and they stick.

You don't need a session to know if an object that you're saving
corresponds to an insert or an update either, since that information is
sitting right there in the databases.

As I say, maybe I misunderstood your question though.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

 

[James Crosswell]

Thanks Frans, it sounds interesting. My brother had already sent me a
link to your products actually but I didn't look any further (because it
was a code generation framework).

I guess I should take another look some time - although by now I've
actually managed to work around all the issues I mentioned using the
above frameworks, so it's kind of academic for existing projects. Maybe
for a new project I'll take a look though.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net