Great job James :).
On Wed, Jan 14, 2009 at 12:31 AM, Paul Batum wrote:
> Your blog post is exactly what I think needed to happen. You did an
> excellent job of keeping it unbiased. Thank you very much James.
>
> Paul Batum
>
>
> On Wed, Jan 14, 2009 at 8:24 AM, James Gregory wrote:
>
>> Well I'
Your blog post is exactly what I think needed to happen. You did an
excellent job of keeping it unbiased. Thank you very much James.
Paul Batum
On Wed, Jan 14, 2009 at 8:24 AM, James Gregory wrote:
> Well I've gone and done it, I've committed these changes and blogged about
> it.
> You can find
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
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
archit
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 nhiber
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 solut
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 t
>
> 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
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 propert
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
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
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
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 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 -
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 wr
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.
+1 for the same reason Paul said that it doesn't require changes to class map.
-Original Message-
From: Paul Batum
To: fluent-nhibernate@googlegroups.com
Sent: Sun, 11 Jan 2009 6:33 pm
Subject: [fluent-nhib] Re: Mapping private properties
+1
I really like how it
+1
I really like how it looks, and I like how it means there are zero changes
to class map this way.
Paul Batum
On Mon, Jan 12, 2009 at 8:14 AM, Tuna Toksöz wrote:
> Great idea, looks good to me.
>
>
> Tuna Toksöz
> http://tunatoksoz.com
>
> Typos included to enhance the readers attention!
>
>
Great idea, looks good to me.
Tuna Toksöz
http://tunatoksoz.com
Typos included to enhance the readers attention!
On Sun, Jan 11, 2009 at 10:57 PM, James Gregory wrote:
> Guys,
> We've been quite regularily receiving requests and/or complaints about not
> being able to map private and protect
18 matches
Mail list logo
