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