Great job James :). On Wed, Jan 14, 2009 at 12:31 AM, Paul Batum <paul.ba...@gmail.com> 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 <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.com@ >>>> 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 -~----------~----~----~----~------~----~------~--~---
