Frans,
I come from the J2E world. The reality is that what you call the "entity
service" finally gave birth to non sense like JPA.
Like a "Layered abstracted layer".
The Srping example is good to : it does so many thing that it has become
a living hell to use. (Not the .Net version, but at least the Java One)
What entity services would you need when you are using POCO exactly ?
Code generation ? For a enterprise scale project, most of time it is
internaly designed
Aspect Weaving ? Code Injection ? These are performance killers.
As long as the persistence engine is not intrusive in the way I model my
objects or my business is logic, the rest is useless.
I'm fine with Nhibernate because it does exactly what it is mean to do :
persisting a domain
More over, it gaves me options, ressources and a non intrusive model.
Perhaps due to my experience, but I don't really care about the Linq
stuff (except over object because it is a good compromise) or the nth
layer over or the facade libs. The same as a good whiskey, I like it
straight.
I tried all the ORM framework before choosing NHibernate. Sure EF isn't
sitting on its hands. But it is not what is required at corporate level.
Perhaps with EF 7 it will be ok ?
I think that any architect working on complexes and non trivials domain
models don't care about the visual designer, the tooling.
We care about integrity, performance, testability, transparency. Playing
around with class diagram is not that fun. Generating code from legacy
database, well...
Fred
Le 28/08/2010 22:45, Frans Bouma a écrit :
On Sat, Aug 28, 2010 at 3:33 PM, Frans Bouma<[email protected]> wrote:
The reason I asked is because for me to provide a
solid layer on top of NH for what my work does is difficult besides
the
persistence part: all other stuff is scattered around in a dozen
projects
with various quality, docs, etc. while all of it is in fact only
usable with
NH, so IMHO it's better for users of NH if the 'package' NH simply
brings
everything you need to the table: persistence _and_ entity services.
As you said, it is better for you.
Why is something that's better for me NOT better for everyone else?
Any NH user, simply adds features at the framework level, without having to
spend hours finding 'a' solution 'somewhere'.
One of the reasons of the NHibernate success is exactly due to the fact
that
it has a clear responsibility: persist your domain.
That is all.
I run around in O/R mapper land for a long time now. There were
years when O/R mapper developers in .NET land got together and had long
talks about software architecture, what could be needed etc. One thing we
agreed on a long time ago was entity services were necessary to make using
an o/r mapper really worthwhile. Persistence is just about pushing objects
back/forth to the db, NH already solved that problem years ago. It's the
added value of these services which makes a framework usable.
As your focus seems to be on persisting the domain, I truly hope for
all developers who write software on top of NH that NH's focus will move
beyond solely persisting 'the domain', if it only for example was because MS
isn't sitting on its hands with EF...
FB
--
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.
