How about "Autumn of Fluent NHibernate". The other title could be misunderstood... :)
On Mon, Aug 3, 2009 at 7:48 AM, Berryl Hesh <[email protected]> wrote: > > Hi Steve. > > How about the "Fall of Fluent NHibernate" for your next major video > production? Kind of just rolls off the tongue, doesn't it?? > > Seriously, good to see you having a hard look at FNH! > > Berryl > > On Aug 1, 9:00 am, sbohlen <[email protected]> wrote: > > James: > > > > I get it now (I must be a little thick, I guess). You're suggesting > > to use a private auto-property as a 'stand-in' for the 'role' of a > > field and then map directly to the private autoproperty using FNH...? > > > > Yes, I do think this approach would work; it just requires a sort of > > mental shift (on my part) about the use of properties; in this > > approach where I would (usually) use a private field, I should instead > > use a private autoproperty. Makes sense, and the (slight) overhead of > > accessing the private autoproperty vs a private field in my object > > model should be near-completely imperceptible (unless doing something > > inane like accessing it 1M times in a tight loop <g>). > > > > Thanks for the info on 'Reveal'; that was very helpful. The 'nested- > > class' approach delineated in that section of the wiki is basically > > accomplishing the same thing as I was hinting at in my prior post > > using code-gen techniques at compile-time to create strongly-typed > > field-wrapping-properties for persisted entities; the code-gen > > approach typically involves declaring the 'hand-written class' and the > > 'code-generated class' using the 'partial' keyword and the nested > > class is code-gen-ed by the template and merged into the 'hand- > > written' class at compile-time. You don't get design-time > > intellisense support for mapping statements until *after* a first > > compile (to fire off the template), but you also needn't maintain > > these nested classes by hand either. > > > > Obviously there are pros and cons to all of these strategies, but they > > all accomplish somewhat the same thing: (semi-) automatic strongly- > > typed access to private fields in persisted classes in lambda > > expressions. > > > > I completely agree that in my case FNH may very well not suit my > > 'typical' implementation pattern for some of the ways that I prefer to > > use NH and I'm not so much suggesting that it change in any way to > > meet my needs but am more just trying to explore the relative pros and > > cons of how well (or not) it aligns with my usual usage patterns, of > > course. > > > > Thanks for all the info and I will continue to explore all of this in > > greater detail. > > > > -Steve B. > > > > On Aug 1, 8:22 am, James Gregory <[email protected]> wrote: > > > > > > Since my usual architectural approach to using NH typically involves > mapping > > > > fields rather than properties (auto or not), obviously none of my > properties > > > > *can* be auto-properties since auto-properties (sadly) don't have > > > > predicatably-named backing stores that I could map to using > 'traditional' > > > > non-FNH approaches (e.g., XML). > > > > > You sure about that? If FNH can do it, NH can do it... AFAIK you just > map a > > > private autoproperty the same as a regular public property, no need to > > > specify any access strategy. > > > > > You can find info about Reveal at the bottom of this wiki > > > page< > http://wiki.fluentnhibernate.org/show/StandardMappingPrivateProperties> > > > . > > > > > The fact is, fluent isn't going to fit with everybody's style; I > wouldn't > > > expect anyone to change their design to use FNH, just as I wouldn't > expect > > > anyone to change to use NH. If your design is compatible, then that's > where > > > FNH can be of use, if it isn't then there's not much use trying to mash > one > > > into the other. > > > > > Fields will be supported, but there's always going to be some > compromise > > > around inaccessible ones. > > > > > On Sat, Aug 1, 2009 at 12:41 PM, sbohlen <[email protected]> wrote: > > > > > > Paul: > > > > > > Good points -- I may be inadvertently conflating PUBLIC > autoproperties > > > > with PRIVATE autoproperties (and also PROPERTIES with AUTOPROPERTIES) > > > > here. Honestly it never occured to me to have private properties > > > > (again, auto or not) on my objects even though there's clearly no > > > > compiler-rule that says I can't so I think when I read 'property' in > > > > the above thread my mind immediately just inferred 'public' > > > > accessibility for them. > > > > > > Since my usual architectural approach to using NH typically involves > > > > mapping fields rather than properties (auto or not), obviously none > of > > > > my properties *can* be auto-properties since auto-properties (sadly) > > > > don't have predicatably-named backing stores that I could map to > using > > > > 'traditional' non-FNH approaches (e.g., XML). > > > > > > Given James' reply, I can see TWO issues that would seemingly need to > > > > be overcome here: one being that everything would of course need to > > > > have an option to be expressed in terms of FieldInfo rather than > > > > PropertyInfo, and the other being how do you get the > lamba-reflection- > > > > trick to work against private members. The FieldInfo v PropertyInfo > > > > issue is straightforward, but can you point me to a reference (blog > > > > post, whatever) that demonstrates what mapping to a private property > > > > would look like (using this 'Reveal' option) --? I would like to > > > > explore what this looks like as a semi-viable alternative to having > to > > > > expose all data-bound values in my objects as public properties even > > > > though I agree with James' post that this renders much of the benefit > > > > of FNH impotent. > > > > > > Unfortunately, the only non-string-dependent way that I am aware of > to > > > > access private members via anything similar to the lamda-reflection- > > > > hack is to do code-gen to create a parallel class hierarchy, each > > > > parallel class full of properties that correlate exactly to both the > > > > public and private members of your objects so that you can express > the > > > > private members in lamba statements. This is obviously significantly > > > > less than idea b/c you're just moving the responsibility for keeping > > > > things 'logically consistent' from string-literals to whatever your > > > > code-gen executable is, but I have seen this approach generally work > > > > leveraging the somewhat flakey integration of VS and the T4 > templating > > > > engine. Obviously this approach is counter to (or at least different > > > > from) what you're trying to accomplish with FNH, but I have seen it > > > > work. > > > > > > Thanks again for the suggestions; in the end it may just be that the > > > > overall architectural approach that FNH is taking (using the lamda- > > > > reflection-hack to avoid string-literals) is simply incompatible with > > > > my general approach of mapping to private fields in objects (square > > > > peg, meet round hole <g>). > > > > > > -Steve B. > > > > > > On Jul 31, 8:27 pm, Paul Batum <[email protected]> wrote: > > > > > Stephen, > > > > > > > I'd just like to point out that private auto properties > > > > > > > a) Cannot have any logic in getters and setters > > > > > b) Do not appear in the public interface of your domain objects. > > > > > > > i.e. Neither of your objections apply when replacing your private > fields > > > > > with private auto properties. > > > > > > > Of course, to map to those private autoproperties you need to > either give > > > > up > > > > > some compile time safety (by using Reveal as James mentioned, or > mapping > > > > to > > > > > a public property and then using an access modifier), or sacrifice > > > > "domain > > > > > purity" and nest your mappings inside your entities. > > > > > > > Paul Batum > > > > > > > On Sat, Aug 1, 2009 at 3:13 AM, James Gregory < > [email protected] > > > > >wrote: > > > > > > > > We do have full intention of supporting as much of fields as we > can, > > > > but > > > > > > it's not a high priority right now (getting the release out with > what > > > > > > everyone's already been using for the past year is). There's > always > > > > going to > > > > > > be trouble around private fields that don't have a public getter, > > > > because we > > > > > > can't access them via a lambda, but we can always provide string > based > > > > > > alternatives (however much that undoes one of the key strengths > of > > > > FNH); for > > > > > > example the Reveal functionality does allow you to use private > > > > properties > > > > > > currently, if you're willing to use strings. > > > > > > > > The whole issue is that our entire public interface is based on > > > > > > PropertyInfo, it has been from day one. I don't think much > > > > consideration was > > > > > > given to fields in the beginning and as such they've kind-of > fallen to > > > > the > > > > > > wayside. It's clear what we have to do (replace all instances of > > > > PropertyInfo with some higher-level abstraction that could be a > PropertyInfo > > > > or FieldInfo (or MethodInfo!) under the hood), it's just a matter of > getting > > > > the time and resources to do it. > > > > > > > > There isn't any voting happening because we're already decided > that we > > > > will > > > > > > support fields, we were a long time ago :) > > > > > > > > As always, patches are welcome ;) > > > > > > > > On Fri, Jul 31, 2009 at 4:30 PM, sbohlen <[email protected]> > wrote: > > > > > > > >> Just FYI for some perspective, many people (like me!) prefer > field > > > > > >> mappings to property mappings for at least two (and probably > more) > > > > > >> reasons: > > > > > > > >> 1) we want to bypass (any) side-effects of setters/getters when > > > > > >> hydrating/persisting entities; yes, setters/getters with > side-effects > > > > > >> are *generally* a code-smell but there are legitimate use-cases > that I > > > > > >> don't want persistence-concerns to inadvertently trigger > > > > > > > >> 2) property mappings lead to needlessly verbose public surface > areas > > > > > >> on entities; not everything an entity needs from the database to > do > > > > > >> its work is a good idea to expose to the outside consumer of > that > > > > > >> entity (field-mappings more easily support the > entity-as-domain-object > > > > > >> instead of the entity-as-DTO pattern that property-mappings > encourage) > > > > > > > >> If we are voting (and FWIW I'm not sure we are!), I personally > would > > > > > >> like support for field-level mappings ASAP; for me its a major > > > > > >> concession in the design of my domain model for persistence to > only > > > > > >> support property mappings and FNH needs influencing the shape of > my > > > > > >> domain objects feels like tail-wags-dog in many cases. > > > > > > > >> Just my $0.02 > > > > > > > >> -Steve B. > > > > > > > >> On Jul 30, > > > > ... > > > > read more ยป > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
