Well I've gone and done it, I've committed these changes and blogged about
it.
You can find my (hopefully reasonably unbiased) post about it on my blog:
http://blog.jagregory.com/2009/01/13/fluent-nhibernate-mapping-private-and-protected-properties/
I've already stated where my preferences lay on this, but I've come around
to the idea that people at least need to know their options.
On Tue, Jan 13, 2009 at 12:39 PM, James Gregory <jagregory....@gmail.com>wrote:
> FNH is opinionated by architecture, whether or not that was deliberate
> doesn't matter (it probably wasn't), but if the current architecture doesn't
> allow something then you shouldn't fight it (I'm differentiating between
> unimplemented features and something that isn't possible because of the
> architecture here). Find something that does support what you want to do.
> However... I think you've convinced me that we need to make some kind of
> statement. I'll knock together a post tonight that'll look something like
> this:
>
> - Outline all available options
> - Give pros and cons for each
> - Stipulate there is no "right way" to do it, only what suits the
> individual domain/developer
>
> This will essentially mean that all our options are recommended by us,
> dependent on your personal preferences and decisions. Don't like changing
> your entities, but don't mind using a few strings (with their risks)? Use
> the Reveal. Do mind using strings, but don't mind changing your entities?
> Use the expression trick, or the nested map.
>
> How does that sound?
>
> On Tue, Jan 13, 2009 at 11:51 AM, Paul Batum <paul.ba...@gmail.com> wrote:
>
>> I agree, all these solutions feel like hacks. But the problem is that we
>> seem to have no recourse! C# 3.0 only provides a few possible solutions and
>> NONE of them are perfect. As software developers, compromise is *what we
>> do*, day in, day out.
>>
>> What was the context, when you said that fluent nhibernate is opinionated?
>> I agree that the stuff in the Framework assembly is -very- opinionated, but
>> it also does not get much love. The automapping is opinionated but any
>> convention based approach has to be. That said, the automapping should still
>> provide people with ability to override all those conventions.
>>
>> Imagine the fluent nhibernate code base in 3 years time. Almost all of it
>> has been rewritten and we support 100% of the hbm xml features. Can you give
>> me an example of the type of domain design that you imagine would cause too
>> much friction and be best off using hbm xml? I can't. I would like to think
>> that by then we could handle ANYTHING that anyone could throw at us. There
>> will be people with the awful legacy databases that might have to avoid
>> automapping because it simply isn't worth the effort, but hopefully they
>> would still be better off using fluent nhibernate in "manual" mode.
>>
>> Perhaps by then we would be well underway on "nhibernate on rails", the
>> sort of thing that Jeremy pictured. I believe that there is still merit in
>> the idea of a highly opinionated nhibernate based application framework, and
>> that it could be great. But I don't see why the core functionality that we
>> delivery today has to be opinionated.
>>
>> Paul Batum
>>
>>
>> On Tue, Jan 13, 2009 at 10:21 PM, James Gregory
>> <jagregory....@gmail.com>wrote:
>>
>>> That's fair enough, and I'm reluctant to debate on this issue because
>>> domain design is such a subjective issue. For example, for myself there
>>> currently aren't any options to fluently map an entity with
>>> private/protected members and keep my entities the way I want.
>>> My problem is that all these solutions feel like a hack, that's why I'm
>>> reluctant to endorse them. There isn't a proper architected solution to it.
>>> I don't want to do anything to my entities to support fluent nhibernate, and
>>> to compromise on this is exactly that - a compromise, it's not a perfect
>>> solution, and not one I'd endorse.
>>>
>>> I said this last night elsewhere, but Fluent NHibernate is opinionated.
>>> The more you try to make it work with a design of domain that doesn't match
>>> up with FNHs idea of a domain, then you're going to meet with friction. If
>>> you want fine grained control of your domain, then you're better suited
>>> going elsewhere. Perhaps that isn't the message you want to give out, but
>>> I'd much rather have that message than lure people in and then have to break
>>> it to them that they have to change their domain model to suite.
>>>
>>> Maybe FNHs idea of a domain is wrong here (I'm more than willing to
>>> accept that, and we can work on changing it), but as far as official answers
>>> go "this isn't supported (yet)" is a perfectly valid answer. We've used it
>>> for many other scenarios (indexed collections, many-to-any, any,
>>> complex-ids), I don't see why this particular one is so different. We can't
>>> solve everything with FNH, and shouldn't try to.
>>>
>>> In short, I don't want to give an official answer when the answer is
>>> something I'm not happy with. I'd rather say "not yet", and rearchitect
>>> things until we can give an answer everyone is happy with. No comprimises,
>>> no hacks: a proper, clean, valid solution.
>>>
>>> On Tue, Jan 13, 2009 at 10:59 AM, Paul Batum <paul.ba...@gmail.com>wrote:
>>>
>>>> Perhaps I chose the wrong words. A better example would be the case
>>>> where I have an IList mapped by NHibernate but I want to expose an
>>>> IEnumerable. I make both the getter and setter for the IList protected, and
>>>> make a public IEnumerable getter. I use this pattern very regularly.
>>>>
>>>> I agree with you that automapping is "the future". However a
>>>> sophisticated automapping solution will have to provide the ability to
>>>> override the conventions, and in the most specific of those cases you will
>>>> find us right back to this point about protected/private members. I am sure
>>>> we will also end up with many users that are working with legacy databases
>>>> and automapping will just not be a good option for them. This issue is not
>>>> redundant.
>>>>
>>>> I think fluent nhibernate needs to have at least one official
>>>> *fluent*answer to this. It also needs an official
>>>> *non-fluent* answer, because any fluent answer will be distateful to
>>>> some people. I would like to avoid sending a message that says "if you like
>>>> to carefully scope your domain model then fluent nhibernate is not for
>>>> you".
>>>> We have LOTS of people asking about protected/private members. My goal is
>>>> to
>>>> make sure they know that there is an option that lets them keep their
>>>> entites the way they want AND map them fluently.
>>>>
>>>> Paul Batum
>>>>
>>>>
>>>> On Tue, Jan 13, 2009 at 8:00 PM, James Gregory <jagregory....@gmail.com
>>>> > wrote:
>>>>
>>>>> Sirrocco, you are not alone. I have often used the exact pattern you
>>>>>> are describing. When it comes to domain design I try to make it so that
>>>>>> there is only one way to perform an operation.
>>>>>
>>>>>
>>>>> What's the other way to perform the operation? I'm not seeing the
>>>>> problem with having a public getter, a public setter I can understand, but
>>>>> not just a getter.
>>>>>
>>>>> As far as I'm concerned private/protected properties aren't officially
>>>>> supported,
>>>>> but there are some unofficial workarounds available. There's a big
>>>>> difference between showing people some (albeit hacky) alternatives, and
>>>>> them
>>>>> being our endorsed standard.
>>>>> I have a lot of opinions on our various available options (basically, I
>>>>> dislike them all), but as I'm very unlikely to use them, I don't really
>>>>> care
>>>>> either. I would be less inclined to use a nested class, and more willing
>>>>> to
>>>>> sacrifice a little bit of compile time safety for cleanliness, but that's
>>>>> just me. I'm just not convinced enough with any of the trick options to
>>>>> officially endorse them.
>>>>>
>>>>> This is all redundant anyway, because our solutions don't work with
>>>>> automapping; which is the future, I've tasted it.
>>>>>
>>>>> On Tue, Jan 13, 2009 at 3:08 AM, Paul Batum <paul.ba...@gmail.com>wrote:
>>>>>
>>>>>> Sirrocco, you are not alone. I have often used the exact pattern you
>>>>>> are describing. When it comes to domain design I try to make it so that
>>>>>> there is only one way to perform an operation.
>>>>>>
>>>>>> James, I think you are being a little misleading by saying they are
>>>>>> "not supported". Private/protected properties work fine, you just have
>>>>>> to be
>>>>>> prepared to nest a class in your entities, be it the class map or a
>>>>>> helper.
>>>>>> Some people are not prepared to do that, and I really like your proposed
>>>>>> Reveal syntax as a final resort for those people. But personally I see
>>>>>> nothing wrong with us promoting the nesting tricks as another supported
>>>>>> solution, as I am sure there are others out there like me that are
>>>>>> prepared
>>>>>> to sacrifice a tiny bit of entity "cleanliness" for a nice chunk of
>>>>>> compile
>>>>>> time safety.
>>>>>>
>>>>>> Paul Batum
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 13, 2009 at 6:35 AM, James Gregory <jagregory.com@
>>>>>> gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> That's fair enough, but I personally would not focus so much on
>>>>>>> protecting people from themselves and instead focus on educating
>>>>>>> them.
>>>>>>>
>>>>>>> You're welcome to design your domain however you like, just be aware
>>>>>>> that private properties are not supported by Fluent NHibernate, and
>>>>>>> even with this proposal I wouldn't recommend them.
>>>>>>>
>>>>>>> On 1/12/09, sirrocco _ <xavier...@gmail.com> wrote:
>>>>>>> > Well, the thing is that one doesn't know if it's already loaded -
>>>>>>> one might
>>>>>>> > have loaded a list of Tasks then start accessing the Project
>>>>>>> property,
>>>>>>> > because it's convenient.
>>>>>>> > The result of this, unwanted select to the database from people
>>>>>>> that are not
>>>>>>> > aware that a select is being issued . And even if they are aware
>>>>>>> they will
>>>>>>> > say ... just this time :).
>>>>>>> >
>>>>>>> > So, by forcing protected get I am trying to prevent that.
>>>>>>> >
>>>>>>> > On Mon, Jan 12, 2009 at 9:15 PM, James Gregory
>>>>>>> > <jagregory....@gmail.com>wrote:
>>>>>>> >
>>>>>>> >>
>>>>>>> >> I'm not a guru of entity design, but why are you so concerned
>>>>>>> about
>>>>>>> >> someone being able to do that? They already have that instance
>>>>>>> anyway.
>>>>>>> >> You can make the setter private/protected so they can't change it.
>>>>>>> >>
>>>>>>> >> It's important to bare in mind that Fluent NHibernate is, by
>>>>>>> design,
>>>>>>> >> opinionated. Like any opinionated software, the more you resist
>>>>>>> the
>>>>>>> >> harder you make things for yourself.
>>>>>>> >>
>>>>>>> >> On 1/12/09, sirrocco <xavier...@gmail.com> wrote:
>>>>>>> >> >
>>>>>>> >> > That's great news :).
>>>>>>> >> >
>>>>>>> >> > Still, I'd like to understand why this is a big no no .
>>>>>>> >> >
>>>>>>> >> > In my case I had a "Project" that had an IList<Task> TaskList
>>>>>>> and then
>>>>>>> >> > a "Task" would have a
>>>>>>> >> > public Project BelongsToProject{ protected get;set; }.
>>>>>>> >> >
>>>>>>> >> > I am doing this to be able to set Task.BelongsToProject =
>>>>>>> >> > currentProject - when creating a task, But I want to avoid
>>>>>>> >> > someone doing project.TaskList[0].BelongsToProject.
>>>>>>> >> >
>>>>>>> >> > So, is there anything wrong with my approach ? Should I handle
>>>>>>> this
>>>>>>> >> > another way ?
>>>>>>> >> >
>>>>>>> >> > Thanks.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > On Jan 12, 12:24 pm, "James Gregory" <jagregory....@gmail.com>
>>>>>>> wrote:
>>>>>>> >> >> Unless there are any objections to this, I'm going to try to
>>>>>>> write up a
>>>>>>> >> >> post
>>>>>>> >> >> on this tonight and commit the changes; I'm still going to
>>>>>>> downplay
>>>>>>> >> >> this
>>>>>>> >> >> entirely, but I think it is nice for those who really do want
>>>>>>> to use
>>>>>>> >> >> private/protected properties.
>>>>>>> >> >>
>>>>>>> >> >> On Mon, Jan 12, 2009 at 1:13 AM, Brendan Erwin
>>>>>>> >> >> <brendanjer...@gmail.com>wrote:
>>>>>>> >> >>
>>>>>>> >> >> > Maybe you could call the method PrivateProperty and
>>>>>>> >> >> > ProtectedProperty,
>>>>>>> >> >> > just
>>>>>>> >> >> > so it reads even clearer.
>>>>>>> >> >>
>>>>>>> >> >> > On Jan 11, 2009, at 3:57 PM, James Gregory wrote:
>>>>>>> >> >>
>>>>>>> >> >> > Guys,
>>>>>>> >> >> > We've been quite regularily receiving requests and/or
>>>>>>> complaints
>>>>>>> >> >> > about
>>>>>>> >> >> > not
>>>>>>> >> >> > being able to map private and protected properties. I think
>>>>>>> we all
>>>>>>> >> know
>>>>>>> >> >> > why
>>>>>>> >> >> > this isn't possible, and I think we're mostly in agreement
>>>>>>> that
>>>>>>> >> allowing
>>>>>>> >> >> > this is kinda against the purpose of Fluent NHibernate;
>>>>>>> however,
>>>>>>> >> people
>>>>>>> >> >> > still want it. I think it was Chad who suggested that we
>>>>>>> could supply
>>>>>>> >> >> > some
>>>>>>> >> >> > alternative methods that take strings as parameters, as a way
>>>>>>> to make
>>>>>>> >> it
>>>>>>> >> >> > possible but not as intuitive as the lambda mappings (with
>>>>>>> the
>>>>>>> >> >> > purpose
>>>>>>> >> >> > of
>>>>>>> >> >> > making people use the lambdas whenever possible, rather than
>>>>>>> seeing
>>>>>>> >> the
>>>>>>> >> >> > lambda parameter and the string parameter and taking the one
>>>>>>> they
>>>>>>> >> >> > know
>>>>>>> >> >> > best
>>>>>>> >> >> > - the string).
>>>>>>> >> >>
>>>>>>> >> >> > I had an idea of an alternative, and I've knocked up a few
>>>>>>> tests and
>>>>>>> >> it
>>>>>>> >> >> > seems to work.
>>>>>>> >> >>
>>>>>>> >> >> > Map(Reveal.Property<Entity>("PrivatePropertyName"));
>>>>>>> >> >> > HasMany(Reveal.Property<Entity>("PrivateCollection"));
>>>>>>> >> >>
>>>>>>> >> >> > The Reveal in those statements is a static class, and the
>>>>>>> Property
>>>>>>> >> >> > method
>>>>>>> >> >> > takes a property name and a generic type parameter of the
>>>>>>> entity
>>>>>>> >> >> > being
>>>>>>> >> >> > mapped. It then does some expression magic and builds up an
>>>>>>> >> >> > Expression<Func<Entity, object>> object. This essentially
>>>>>>> allows us
>>>>>>> >> >> > to
>>>>>>> >> >> > leave
>>>>>>> >> >> > the mapping completely untouched. No overloads/alternatives
>>>>>>> for every
>>>>>>> >> >> > method, no maintenance nightmare. If people want to use it,
>>>>>>> they're
>>>>>>> >> >> > welcome
>>>>>>> >> >> > to, but the default route is still the lambda expressions.
>>>>>>> >> >>
>>>>>>> >> >> > Any thoughts? I've tested this against Map and HasMany, and I
>>>>>>> haven't
>>>>>>> >> >> > had
>>>>>>> >> >> > any trouble, will test everything else before releasing
>>>>>>> though.
>>>>>>> >> >>
>>>>>>> >> >> > James
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> > >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> >> >
>>>>>>> >>
>>>>>>> >
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Fluent NHibernate" group.
To post to this group, send email to fluent-nhibernate@googlegroups.com
To unsubscribe from this group, send email to
fluent-nhibernate+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fluent-nhibernate?hl=en
-~----------~----~----~----~------~----~------~--~---
