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 -~----------~----~----~----~------~----~------~--~---
