For NHProf we do pretty nothing in NH core. On Mon, Aug 30, 2010 at 8:08 AM, Frans Bouma <[email protected]> wrote:
> > 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]<nhusers%[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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- Fabio Maulo -- 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.
