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 <jagregory....@gmail.com>wrote: > 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.com@ >>>>> 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 -~----------~----~----~----~------~----~------~--~---
