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