Hi, on the child side of a FK relation I want to map both the parent entity and the FK field itself. Example: Order { ID, CustomerID }, Customer { ID, Name } My Order entity shold look like: class Order { int CustomerID; Customer Customer; } This is important as I am migration from Linq2Sql which generates classes following this pattern. I could do: public int CustomerID { get {return Customer.ID; }} However this is not an option as this would fetch the Customer from the database even if only his ID is required. How would I map this scenario? thanks, tobi Updated at 31.07.2010 18:10:43Great! I thought only NHibernate hat that feature but you have it too. I currently have:
which is working fine as it seems. Would you recommend this solution to others or could it be improved? tobi Updated at 02.08.2010 14:38:35Ok, I wasn't seeing the fetch in sql profiler because the property was already loaded by previous code...
I misunderstood your first post: I thought that entities are always lazily loaded even if you get a reference to them or access their ID property. That is how it works in NHibernate: Only accesses to non-key properties trigger a load from the database. Look at the code snippet in http://ayende.com/Blog/archive/2009/04/ ... ng-by.aspx. The call to Load never goes to the database. Might be a nice feature in DO.NET... Now, how do I assign the CalendarID eg. write the setter without loading the entity from the database? This is important because I am migrating from L2S which allows to do that so I was relying on it. Updated at 02.08.2010 18:59:25I agree with both your an Ayendes reasoning. There are tradeoffs involved when picking the solution. I think there are situations where you would never want a proxy and situations where you can afford it. Why don't you just make it configurable? Then you would make all those NH user quiet who probably are laughing because you don't have their nice feature. I personally would opt for proxies to increase performance and ease development. This thread was imported from our support forum. The original discussion may contain more detailed answer. |
I'm going to surprise you :) :
Forgot to add: to ensure Order.Customer is loaded along with some query returning Order objects, use: 1) either .Select(order => new {order, customer = order.Customer}) - in this case it will be fetched along with your query (btw, and will be available via order.Customer) 2) or use .Prefetch method(s) - this is described in Manual. We use different approach, and actually there is strong reasoning about this. Read my comments to this post of Ayende: Frankly speaking, I just didn't want to argue about this - our view on this issue seems completely opposite. Earlier we had an argue with Oren about exactly the same case: As far as I remember, there was a continuation via e-mail, but anyway, the idea is clear. Few more posts:
Some consequences related to DO4:
See this comment as well, it describes some consequences of returning base type's proxy instead of proxy of correct type: Actually, I can't imagine what we must do if Entity of wrong type is replaced by correct one, when type becomes known:
Actually, there is a good solution of this problem: don't use inheritance, if you want to avoid this. Or, more precisely, use hierarchies with just one type. It's precisely known there are no any trade-offs in this case. But if there is inheritance, you'll anyway get some of them. Btw, today he published one more good post: http://ayende.com/Blog/archive/2010/08/ ... witch.aspx How this is applied to this case? Well, inheritance is a leaky abstraction in case with databases. In fact, it's simulated, but not supported directly, so you must be aware about possible side effects of this. And concerning supporting proxy-related features of NH: this is pretty far from concepts we're implementing. Such things can be done, but: a) Likely, not many people will really use them; the alternative is already available, so "doing this in NH way" is just one more approach b) We're trying to avoid the case when concept gets "dissolved" in features during implementation. So "fitting well" is one more factor we consider. No, this should be improved to the solution I proposed: you're reading Calendar field here, which may (at least, in many cases) lead to lazy fetch of Calendar instance. |