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