> Hey Frans I see where your coming from. I am a new NH user and it would be
> nice to have to worry about the things you listed here.
Of course, because your client pays you to worry about the code you
need to write for them, not about where to get which plumbing element with
which version and where to read up about how to use it.
> However I don't believe anyone has said flat out no to your idea. I
believe
> whats going on here is that no one so far wants to take on the burden of
> implementing the things you have listed here.
most of the things are already implemented. What I refered to as
'no' is the lack of *any* support _here_ for the idea that focusing on a
central list of functionality, and commit to that for a given release is
better than sitting back and wait till someone, if ever, supplies a patch
for something, likely not relevant for may except themselves. Nothing wrong
with that, they volunteered their own time, but it's bad for the project.
See http://mono-project.com/Todo for example. Mono is an example of
how things are driven using 'this is what we have to do, pick a topic and
start working on it'. This avoids the lack of updates in areas where you
want to see it (as no-one knows what you're looking for) and more than
enough updates in other areas. It at the same time also gives an overview of
where dev support is needed so potential contributers can focus on those
areas.
It's not a turn-key solution for success of course: complex topics
like a linq provider are also a problem with Mono, simply because it takes a
lot of time and dedication to complete it.
> In the Open Source community
> problems only seem to get solved by the developers who have an itch and
the
> will and free time to fix it. If this really is a big itch for you and you
> would like to see NH crush EF by adding these features then I think
everyone
> including Fabio is saying go ahead and implement it.
Crushing EF is only going to happen if MS loses interest. This is
not unlikely considering the fact they've done this before a couple of
times. Implementing this requires that everything is released as 1 package.
I don't control that, so no I won't spend time on this.
Another reason why motivation for that has sunk really low is the
not very friendly response I got for my simple question. Instead of
"Interesting idea, why do you ask it?", I got responses as if I had no clue
how OSS works or how an o/r mapper works and what's important.
> The only problem I have with your idea so far is that you want the GA of
NH
> tied to the release of these higher level projects. For me that would be a
> bad thing as a user of NH; the only way that works is if the main NH team
is
> closely tied to the development of these higher level projects.
Yes, and it's called 'quality assurance'. Another bad word. You
release a single package, everything is in there, go ahead, we tested it all
together. Companies would then be friendlier towards accepting it, because
it's not a collected bunch of dlls from various sites, but 1 package,
tested. For the people who want to sell support for NHibernate, it's easier
too: there's 1 package, quality controlled, tested.
It's a bigger project than solely the persistence layer, but gee,
it's 2010, persistence of objects is a problem solved many years ago, things
have moved on since then as persistence isn't a stand-alone problem: your
entities move through your application's code.
> A potentially better way would be to leverage some sort of automation that
> monitors trunk and continuously rebuilds the higher level projects as
> changes are made and re runs the unit tests for those projects. That
> wouldn't prevent a NH GA from going out if the higher level projects broke
> but it would shorten the time between a GA of NH and the GA of the higher
> level libs. Another potential option would be to simply do what the FNH
devs
> have done and package NH alongside your Higher level projects,
<sarcasm>you
> could call it NH#</sarcasm>.
Hodgepodge. you have to focus on the bigger picture: perhaps NH
needs some extension points for additional features in a separate library
(it got those for NHProf, why not for others?)
> The beauty of those proposed solutions is it allows NH to continue to do
> what it does best, persistence.
Object persistence is not very hard. Every simple O/R mapper can do
that. Things get different when you look beyond the object persistence.
> If hooks are needed in NH that do not
> currently exist then the maintainer of the higher level projects can file
> JIRA issues and work with the NH team to get them implemented. If some
other
> developer hates the way something in NH# is implemented they are free to
> start from scratch with a persistence mechanism that's stood the test of
> time. On the other hand, if Microsoft's vertical integration of EF into
> every .NET framework takes off I am sure some developer that hates working
> with EF will build a set of libraries that vertically integrate NH into
> those .NET frameworks that they use, and waits for some one else to do the
> other frameworks they care less about. C'est la vie, and such is the open
> source way.
I think it's more a matter of 'it's the NH way'.
FB
>
> On Aug 29, 4:56 am, "Frans Bouma" <[email protected]> wrote:
> > > 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.
--
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.
