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
>
