Which is the sense NHibernate.Core, that should be the only one referenced by frameworks depending on NH as NHV, NHSR, NHSP, NHE, NHCH, ConfORM), if NH has an embedded dynamic-proxy system ?
On Sun, Mar 13, 2011 at 6:31 PM, Stephen Bohlen <[email protected]> wrote: > As discussed elsewhere, Fabio (with some periodic input from myself) has > been working to define NuGet packaging structures for NH3.x. > > As presently designed, the packaging structure for NH3.x looks like this > (*generalized* so you get the idea; this is NOT exactly their full contents, > but an abstract of how they are structured): > > ******** > Package: NHibernate > Semantic Contents: the nhibernate.dll assembly > Dependencies: none > ******** > Package: NHibernate.Castle > Semantic Contents: the ProxyFactoryFactory for Castle > Dependencies: "NHibernate", <the Castle dynamic proxy assembly(ies)> > ******** > Package: NHibernate.LinFu > Semantic Contents: the ProxyFactoryFactory for LinFu > Dependencies: "NHibernate", <the LinFu dynamic proxy assembly(ies)> > ******** > Package: NHibernate.Spring > Semantic Contents: the ProxyFactoryFactory for Spring.NET > Dependencies: "NHibernate", <the Spring.NET dynamic proxy assembly(ies)> > ******** > > Essentially, the "Nhibernate" package is 'bare' NH3.x with no > ProxyFactoryFactory included and is intended only to be used as a 'reference > package' for other packages (either created by NH team or otherwise) that > for any particular reason do not want/need any of the specific > ProxyFactoryFactory packages. > > The design intent here was that the 'typical' NH adopter would select one > of the "Nhibernate.<proxyfactory>" packages that was to their liking. > > While this approach would seem to achieve this goal, its not without its > limitations, as many have pointed out in various venues: > > - naming the 'bare' (proxy-less) package simply "NHibernate" is > potentially confusing as its 'generic' name increases the likelihood that > it > will be selected by a high percentage of adopters unaware of the nuances of > needing to select one of the higher-level (ProxyFactoryFactory) packages; > this is likely to result in people adding this package in error and not > ending up with a complete, fully-functional NH-based solution (and no clear > indication to them as to why this is the case) > - this approach requires the NH adopter to make a conscious decision > when adding their desired package re: which ProxyFactoryFactory > infrastructure they want to use; it has been suggested elsewhere that this > represents an "implementation detail" within NH that the vast majority of > NH > adopters should not want/need to concern themselves with > > From the beginning of the introduction of the ProxyFactoryFactory, NH has > refrained from making any one of the ProxyFactoryFactory implementations > 'the default' and has treated all proxy engines equally. If we choose to > shield the user from this implementation detail in our packaging by > providing a 'default' for the 'standard' NH package, then we need to decide > which ProxyFactoryFactory implementation will be that default. > > At first glance, the logical choice seems to be the LinFu proxy engine > since its the the lightest-weight of those available (because its > narrowly-focused on being 'only' a dynamic proxy engine and is not also > trying to be an IoC container at the same time). Because of its more narrow > scope/feature set, its also probably the least-likely to version-collide > with other assemblies in users' projects. > > However, since the Castle dynamic proxy engine is presently the only one of > the several to support the 'full' set of NH features (e.g., lazy > properties), this probably makes it the best choice as the 'default' > ProxyFactoryFactory (at least until features like lazy-properties can be > supported by the LinFu dynamic proxy). > > So I am proposing the following revision to the present packaging approach > and asking for comment/feedback on this re-design: > > ******** > Package: "NHibernate.Core" > Semantic Contents: the nhibernate.dll assembly > Dependencies: none > ******** > Package: NHibernate > Semantic Contents: the ProxyFactoryFactory for Castle > Dependencies: "NHibernate.Core", <the Castle dynamic proxy assembly(ies)> > ******** > Package: NHibernate.Castle > Semantic Contents: the ProxyFactoryFactory for Castle > Dependencies: "NHibernate", <the Castle dynamic proxy assembly(ies)> > ******** > Package: NHibernate.LinFu > Semantic Contents: the ProxyFactoryFactory for LinFu > Dependencies: "NHibernate", <the LinFu dynamic proxy assembly(ies)> > ******** > Package: NHibernate.Spring > Semantic Contents: the ProxyFactoryFactory for Spring.NET > Dependencies: "NHibernate", <the Spring.NET dynamic proxy assembly(ies)> > ******** > > This revised approach is intended to ameliorate most of the perceived > shortcoming of the existing packaging design by: > > - using "NHibernate.Core" as the name of the 'bare' nh package; this > (when present in the NuGet list alongside the new plain 'Nhibernate' > package) should help to discourage users from inappropriately referencing > it > directly (fingers crossed here!) > - making the 'plain' "NHibernate" package a fully-functional > distribution that will "just work" for adopters (provided, of course, that > they properly configure NH once adding the package <g>); its *hoped* that > naming it just plain "NHibernate" will increase the chances that adopters > will select it as the package to add (e.g., its name matches "what they > were > looking for") > - still offering the original ProxyFactoryFactory-specific packages > for those adopters 'more aware' of the pros and cons of their making a > specific choice > > Before we proceed to make any of these modifications, we would like some > feedback re: this planned approach in the following areas: > > 1. please comment on the proposed choice of Castle as the dynamic proxy > engine for the 'default' NH package > 2. please comment on the proposed new structure of package dependencies > > Thanks in advance, > > Steve Bohlen > [email protected] > http://blog.unhandled-exceptions.com > http://twitter.com/sbohlen > -- Fabio Maulo
