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. 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. 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.
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. 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>. The beauty of those proposed solutions is it allows NH to continue to do what it does best, 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. 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.
