> > 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, 1:10 pm, James Gregory <[email protected]> wrote: > > >> > We > > >> > only support using properties currently, all the expression based > > >> > methods expect PropertyInfo's not FieldInfo's. > > >> > Any reason you're using a field over an auto-property? > > > > >> > On Thu, Jul 30, 2009 at 6:07 PM, Mikael Henriksson < > > >> [email protected]>wrote: > > > > >> > > I do Access.AsField that way successfully for my Version > columns... > > > > >> > > 2009/7/30 Fost andy <[email protected]> > > > > >> > >> Hi, > > > > >> > >> I feel a bit silly for asking this but how do I map a field > directly? > > > > >> > >> In traditional hibernate I might want something like: > > > > >> > >> <property name="ss" type="String" access="field"/> > > > > >> > >> How do I achieve this in fluent? > > > > >> > >> I tried Map(x => x.ss).Access.AsField(); > > > > >> > >> but this throws > > >> > >> System.InvalidCastException: Unable to cast object of type > > >> > >> 'System.Reflection.RtFieldInfo' to type > > >> > >> 'System.Reflection.PropertyInfo'. > > > > >> > >> On a whim I tried .SetAttribute("access", "field") but got the > same > > >> > >> error. > > > > >> > >> thanks.- Hide quoted text - > > > > >> > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
