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 <
paul.ba...@gmail.com> 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 <
jagregory....@gmail.com>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 ;)
>
> >> > - Show quoted text -- Hide quoted text -