Hi guys & gals (maybe? probably not) I don't want to mention this for two reasons: #1 - I really like this idea and don't want to be responsible if you decide to kill it. #2 - I am fully aware of the contempt that C# coders have for less developed .NET languages on issues like this.
A lot of this syntax simply won't work in the current version of VB.NET. Thanks, Jason On Jan 19, 2:20 am, Steve Strong <[email protected]> wrote: > That's a pretty comprehensive answer! I can't think of anything else to > add over what you've already said - I think an API for creating the > mappings as a core part of NH would be great, and I also agree that > keeping the syntax similar to the current XML eases the learning curve > and also makes porting from XML to code pretty simple. If other want > some different representation (FNH, for example), they now have a > canonical API that they can talk to under the covers, rather than having > to generate xml as they do today. > > I don't have major concerns about the deviation from Hibernate - it's > certainly something that we should bear in mind, but I can't imagine > anything that Hibernate are likely to do wouldn't map to this new API - > anything they add is likely to be configured through XML (I don't see > that going away any time soon), and since the proposed API matches the > XML structure quite closely, I can't see that we'll come across anything > insurmountable. > > Cheers, > > Steve > > On 18/01/2010 16:21, Stephen Bohlen wrote: > > > > > First, some quick impressions: > > > * Its conceptually nice to relegate XML mapping to a less-central > > role within NH (e.g., XML now becomes just ONE of MANY possible > > 'mapping input syntax forms') so I applaud the effort/intent > > * Decoupling mapping + config from XML entirely will definitely > > support many more alternate declarative inputs (custom DSL, > > whatever) in a manner much more flexible than having to depend > > on XML as an 'intermediate translation layer' for NH to consume > > mapping/config info > > * I like that the thrust of the syntax more closely parallels the > > nodes/attributes used in the XML files, making it approachable > > to existing users of XML mapping files (reasonably shallow > > learning curve) even as this leads to a fairly verbose API > > (compared let's say, to something like FNH where 'terse API' was > > --from my reading-- an implicit design goal) > > > Next, some more specific feedback/issues/thoughts/concerns we might > > want to consider (in no particular order): > > > * If this API is to become 'authoritative' for mapping, then by > > extension it clearly needs to completely support all existing > > 'xml constructs' fully > > * Unlike FNH where the authors have taken the entirely valid > > approach of "we're releasing with support for the 80% of NH > > mapping constructs that are most-commonly in use, permitting > > people to weave in xml-based content for the parts we don't yet > > support in code, and over time we will evolve to support the > > remaining 20% edge-cases in the fluent API", IMO for NH this API > > shouldn't be released into the codebase until it has 100% > > functional equivalency with each and every existing XML > > construct and doesn't rely on intermingling xml for any of its > > needs. > > * Obviously as an existing proof-of-concept this isn't yet done > > but it would seem important before making this the authoritative > > API to ensure that adequate spikes are done to be certain that > > for every 'statement' presently possible in XML, there's at > > least an idea about how to express that in this new API (some of > > the edge-cases that come to my mind initially are things like > > the <database-object> elements, stored procedures, filter > > statements, where statements, etc. that aren't immediately > > obvious from the sample code in the blog post re: how they would > > be addressed -- basically the entire category of things > > presently definable in XML that aren't necessarily *directly* > > about mapping entities per-se but that are about caching > > directives, other DB elements, etc.) > > * We need to ensure that adequate consideration is given to how > > this API would express things that aren't immediately possible > > to state as lambda's without some 'tricks' via reflection, etc. > > For example, this kind of statement from the sample code... > > > map.Class<Animal,long>(animal => animal.Id, id => id.Generator > > =Generators.Native, rc => > > ...won't work where the POID is actually not a public property of the > > Animal class but is instead a private field and of course the > > statement (animal => animal._persistentId, ... won't compile b/c the > > private field _persistentId is not visible to intellisense (or more > > importantly, the compiler!). To be sure, there are 'tricks' to get > > around this lambda limitation, but I recommend that we should consider > > carefully what this will look like when invoked via this API to be > > sure its as clear as the public-property-based mappings shown in the > > sample code. > > > * How does moving this fluent-API into the role of 'primary' > > mapping API affect NH's 'parity' with Hibernate? Is it possible > > that Hibernate might get a future feature that would want to be > > ported to NH but we would find that this (hypothetical) new > > feature isn't expressible in the new fluent API? Obviously > > nobody can predict the future, but the move to this API as > > 'primary' mapping API would seem to represent a digression from > > NH's close parity with H which may impact the ease with which > > future features can be ported from H to NH. This new fluent API > > might very well be a useful/valuable digression (and obviously > > there are already OTHER features that have been added to NH that > > take advantage of the .NET platform and don't have an allegory > > in Hibernate so diverting from exact parity with H isn't without > > precedent), but IMO we should carefully consider its potential > > future impact on porting H features to NH before we decide to > > 'deprecate' XML as the primary/core mapping API. > > > In short: I like the approach, think it will be quite valuable and > > helpful to anyone trying to write inputs to the NH mapping/config API > > in the future, but recommend that we consider the above > > issues/thoughts before introducing this API as a 'replacement' for the > > primacy of the xml API in the project. > > > HTH, > > > Steve Bohlen > > [email protected] <mailto:[email protected]> > >http://blog.unhandled-exceptions.com > >http://twitter.com/sbohlen > > > On Sun, Jan 17, 2010 at 5:40 PM, Fabio Maulo <[email protected] > > <mailto:[email protected]>> wrote: > > > Please, I'm needing feed-back coming from code-review. > > > Try to think at it as a possible mapping-by-code solution for NH3.0. > > I'm seriously thinking to add it in NH directly. > > > 2010/1/13 Fabio Maulo <[email protected] > > <mailto:[email protected]>> > > > Hi team. > > > I would like to have a code re-view of my last post and > > a constructive feedback > > > > http://fabiomaulo.blogspot.com/2010/01/map-nhibernate-using-your-api.... > > > The post, and overall the code, is basically an example about > > how implement a custom API to create mappings by code. > > That is an invitation to everybody want create his own API and > > even an invitation for FNH team to use the Hbm* classes > > instead generate XML. > > > That said, seeing how things are going in each framework, NH > > needs its own mapping-by-code. > > Two matters here: > > 1) API definition > > 2) usage of Hbm* or directly create metadata (classes of > > namespace NHibernate.Mapping) > > > What is clear is that our implementation will supports > > anything supported by XML and, probably, we will improve some > > of actual "conventions-interceptors" (as, for instance, > > INamingStrategy & Co. ). > > > -- > > Fabio Maulo > > > -- > > Fabio Maulo
