> Frans, about:
> > Features of an O/R mapper can be divided in a couple of groups:
> > persistence and entity management.
>
> Can you write down a list of entity management features are you thinking
> about?
I did mention some, in the email you quoted from. let's see (I know
most of these elements already have implementations somewhere, that's not
the point)
- Validation
- Authorization
- Auditing
- OData support
- Databinding aware interface implementation in proxies
- value rollback when subgraphs are bound to controls in a form and the user
hits 'cancel' (so in-memory value undo/redo)
- in-memory relationship syncing (setting myOrder.Customer to myCustomer
adds myOrder to myCustomer.Orders)
- a datasource control with design time support for asp.net
- etc.
Some are 'add-ons' (live on top of the entity classes / o/r mapper),
others are used inside the o/r mapper core.
The idea is: if someone downloads NH 3.0, he gets a box with all the
elements above as well. Not inside NHibernate.dll, but it's in the download,
documentation is there in 1 spot. The main advantage: if NH is released, the
add-ons are as well, in 1 package. If NH breaks something in an add-on, it
is fixed before NH goes GA, because the add-on is part of the package.
You don't have to use any of it, but it's there for the people who
do want to use it. Some replies in this thread are in the sense of "I don't
use it, so why bother", which IMHO is closed minded, because developing a
framework is by definition doing it for others, not yourself. Those others
have different needs, do things differently.
> > ..... Entity services is
> > what makes an O/R mapper usable and stand out in the crowd.
>
> Evidence? Popular ORM "stand out in the crowd" because it has "entity
> management"?
well, otherwise you can use any persistence engine, of which there
are (still) plenty.
> My guess: Hibernate, and NHibernate, are focused on persistence. And then,
> they are standing out in the crowd. In my experience, having a framework
> doing a lot of things, could make it complex and less usable (.NET
evidence:
> FULL Spring framework in .NET is not taking the world by storm).
I don't see spring.net equal to NH, do you? If it's solely about
persistence, you can also use EUSS, or opf3. Both open source.
> But maybe I missed your point: I don't have a clear picture of "entity
> management" features you mentioned.
Think about the large group of people who do EF, datasets etc.
today, those people don't use NH. They likely will write software completely
different from how you do it. The thing is: today, NH comes without the
fluff they are used to and have a hard time getting started. You can of
course hope that they will change the way they create software, but chances
are that's not going to happen. So they instead will look for something
easier.
If NH's focus in solely on 'persistence' and that the rest of it
should be somewhere else, preferably super far away in some unnamed side
project and most people here (at least the people who replied) see it as 'it
will make things worse', then how are you planning to win from EF for
example? By claiming it sucks? Or by giving a true valuable alternative?
Yes, you have the persistence covered, but it doesn't end there.
> I like you want to build a solid layer over Nhibernate, but I guess your
> approach (trying to add features, scattered over other projects), it's not
> the way.
>
> > If someone wants to get started with NHibernate today, and for
> > example wants to include INotifyPropertyChanged, auditing, some user
> > types, and authorization for example, that user is in for a hell of a
> > long trip to a long strain of blogposts, trial/error articles which
> > don't match his situation, outdated nh docs, the various contrib
> > libraries which come with only code as documentation and has to get
> > that up and running next to mapping files and the like.
>
> Yes, but my opinion: that user should add such features as in any other
> project, working over POCOs or alike, using approaches not linked to
> NHibernate. Contrib project are great resources, but if they would be part
> of NHibernate, I would feel a great lib infected in some strange way.
Why would it be included inside the NH dll? The byte code factories
are separated as well, but still shipped with it.
Simple example: authorization. Say in NH I can define somewhere what
authorizer class instance I should get injected into which entities so the
proxies automatically contain my authorizer and wherever the entity class
goes, the authorizer goes with it. The authorizer is a simple class which
gets a call if something is done to the entity class, e.g. reading a
property. The authorizer then should validate that call, how, that's up to
the developer.
This way I can have code like this:
var theCCNumber = customer.CCNumber;
which returns an empty string for user X and the CC number for user
Y. What did that take? 1) implementing a simple class (e.g. deriving it from
a base class), and configuring it so it gets loaded in every proxy. Done.
It's about making life _easier_ for the users of NH, not harder.
Don't want to use it? don't use it.
Anyway, results up to now: no we don't want your ideas. Ok, noted.
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.
