ok On Fri, Oct 15, 2010 at 5:51 AM, Frans Bouma <[email protected]> wrote:
> First of all, I saw Fabio again mocking my answers on twitter. I can't > believe how stupid and shortsighted this is. Fabio, do you really think I > know jack shit about building and releasing software, what O/R mapper using > people need? > > On NHUsers some french **** insulted me deeply and mr. Maulo just said > nothing, as if he approved. Here, he asks a question, I answer, try to help > out, and from all the answers, mr. Maulo finds it necessary to mock my > answers on twitter, as if I'm an overpayed consultant living in MS Word all > day. I'm not expecting anyone to agree with me, but I don't expect from > professional developers who debate a serious topic to make fun of my > answers. Why, Maulo? Felt threatened? You think I'm stupid and you want > confirmation from others? > > Now let's get back to Diego's reply, which is honest and decent (see, mr. > Maulo? You can also simply debate about technical points of view, and learn > from it perhaps.) > > > All the features you mentioned are definitely outside the bounds of NH > > _core_ That doesn't stop people from creating higher level projects like > > Sharp Architecture, which include ready-to-go stacks. > > In fact, they don't even have to be F/OSS: LGPL allows you to include > > NHibernate as part of a commercial tool/framework that does that and > more. > > I'm not arguing they should be part of the core. That's why I some > time ago said on NHusers, in another endless stupid debate with mr. Maulo > and said french ****, that you have core O/R mapping and entity services. A > couple of years ago we had a meeting between 5-6 O/R mapper developers on a > conference, and debated what direction O/R mapping would go, what things > people would be interested in, just software devs talking tech, not > marketing. We all agreed that the core O/R mapping problem was solved and > done with, but to use it in today's software applications, you need > services > on top of that, or better: developers will build functionality on top of > the > O/R mapping core, utilizing that core and even wanting to integrate with > it, > like validation, security on the db level, auditing, concurrency control, > subclass/proxy functionality etc. etc. It's key for these functionality > elements that they work well with the O/R mapper of choice and work > seamlessly. > > It's therefore key to see 'using NHibernate' equal to 'using > NHibernate as O/R mapper core and additional NHibernate targeting > services'. > Because, they're tied together: you can't use LLBLGen Pro's > auditing/authorization system which is integrated in our core with > NHibernate's and vice versa. > > So it's not about a question whether there IS functionality out > there, I'm sure it's all there somewhere, it's that it: > 1) has to integrate well with the NH core used by the developer > 2) has to be updated when the NH core updates > 3) comes in the same package or at least without the necessity of looking > for all the libs out there. I don't mean, in the same NHibernate.dll, but > shipped with it, so when you download NHibernate, you get everything, and > the _developer_ decides what to use. > > Sure there are high-level stacks, but often they surpass what the > developer is looking for, i.e., they don't want a top-to-bottom framework > where they have to color in some blanks, they want to 'outsource' some > parts > of their architecture to 3rd party libraries: db access to NHibernate, > auditing, validation etc. to nhcontrib stuff etc. and what is picked from > that big box of chocolates could be different for every project, that's the > beauty of it. The point is that it is easy selectable for the developer, so > the developer knows what he's using is up to date, works together and is > right there, so no hunting across an endless stream of > sites/blogposts/defunct sourceforge projects etc. > > FB > > > > > Diego > > > > > > > > On Thu, Oct 14, 2010 at 15:31, Frans Bouma <[email protected]> wrote: > > > > > > The examples I mentioned are not things you expect on the core O/R > > mapper > > level, however they're all services which build on top of the O/R > > mapper > > core and utilize it, which also means that if you use NHibernate, > and > > you > > want to use the features I mentioned, you need to implement them > > somehow so > > they utilize NHibernate. > > > > That initially takes time, which shouldn't be necessary. > > > > > > > - auditing <= outside NH scope. There are various interpretations > > of what > > > mean "auditing". In the NH3 cookbook you have 3 solutions without > > need to > > > add external references. Simon and Roger are working on the port > of > > Envers > > > that is another interpretation about what mean "auditing". > > > > > > to track which user read / wrote which property, you need to > > emit > > code in the proxies, there's no way around that. If you want to > auto- > > persist > > audit info in entities when the transaction commits, you need to > > write > > interceptors (IIRC). I'm sure it's already been done a couple of > > times, but > > that's not the point. The point is: the user now has to hunt down > > where to > > get the auditing functionality so it's added to the complete stack > of > > persisting and reading entities. > > > > > > > - validation <= outside NH scope and, btw, you have at least > others > > 4 > > > frameworks we the specific responsibility of validate objects. > > > DataAnnotations, VAB, Castle, Spring, FluentValidation and so on. > > Validation > > > is a cross cutting concern, NH give you the ability to inject the > > validation > > > of your objects before persist it (on Save, update.... or just > > before > > flush > > > the session). > > > > > > Same thing as auditing: it's been done before, but what if > > someone > > wants to enable it, e.g. enable field level validation with > > IDataErrorInfo > > without having to write endless piles of code? Or auto > > string/bytearray > > length checks based on mapping info, or decimal precision/scale > > checks? > > That's stuff that's 'very handy to have', and should be enableable > > through a > > setting, not by hunting down code which might be outdated. > > > > > - INotifyPropertyChanged <= I have no idea about what mean to > give > > support > > > > > to INotifyPropertyChanged. NH is not a code-generator to generate > > entities. > > > If your entities implements INotifyPropertyChanged for NH there > is > > no > > > problem. If, in your opinion, you can take some advantage > > implementing > > > INotifyPropertyChanged you can do it with less than 50 code > lines: > > > http://fabiomaulo.blogspot.com/2010/10/turbo-nhibernate-with- > > domain- > > > invaders.html > > > > > > I was refering to auto emitting the interface in the > proxies. > > You > > refer to a blogpost, which proves my point. > > > > > > > - security <= I'm inclined to say that again it is outside NH > scope > > but I > > > would understand which kind of "security" you are talking about. > > > > > > yes, security on the persistence level. > > > > Additionally, if someone wants to 2-way bind entities in an > > asp.net > > page with a datasourcecontrol, is that available? I'm sure someone > > has > > written it, but where is it? Things like that make developing code > > _easier_. > > 'less friction' is a term I have heard often, well, this is a big > > friction > > releaving thing. > > > > > > FB > > > > > > > > > > > On Thu, Oct 14, 2010 at 2:19 PM, Frans Bouma <[email protected]> > wrote: > > > > > > > > > 1st: I'd like to state that if I post here, I don't like it > > when I > > > see what > > > I posted questioned on twitter. if you have questions, ask > > them in a > > > reply > > > > > > 2nd: I meant: if I want for example: > > > - auditing, > > > - validation > > > - INotifyPropertyChanged > > > - security > > > > > > in my application which uses NH, I'd like to do that with > > e.g. > > > configuration > > > elements in the config file, and not having to worry > whether > > I have > > > the > > > latest nightly build of a 0.x versioned lib tucked away in > > some dark > > > corner > > > of sourceforge: that's bad because: > > > 1) what if the lib gets abandoned in a year? Will I still > be > > able to > > > maintain my app? > > > 2) what happens if I update NH because of a bugfix release? > > > > > > FB > > > > > > > > > > On Thu, Oct 14, 2010 at 1:18 PM, Frans Bouma < > [email protected]> > > wrote: > > > > > > > > > > > > - all functionality needed in 1 box, so you can > focus > > on > > what > > > you're > > > > payed > > > > to do. > > > > > > > > > > > > > > > > the last one is not the definition of toolkit, here we > call > > it as > > > > "masacote". > > > > To have all "functionalities needed" (and here I would > > know the > > > definition > > > > of "needed where and to do what") in all > > places/applications where > > > NH is > > > > used, more than 1 box we need a truck. > > > > > > > > -- > > > > Fabio Maulo > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Fabio Maulo > > > > > > > > > > > > > > -- Fabio Maulo
