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
> >
>
>
>
>
