Frans,
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.
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
> >
>
>
>
