Ah yes. A heuristic. What are you on about? Either you load a snapshot or you don't. You don't load a "well here is an idea of what I want thingy majig"....
... of events to get around ORM Umm, I've never suggested that style. The only thing that I believe could reasonably be attributed to me is raising events from...
... We take care of this through query methods/objects and fetching strategies encapsulated in each query. But with the sheer number of view screens, we only...
Hi Greg and Mark, Thank you both for your patience and for answering some of my questions. I'm also patient ... To whoever cares about answering "how correct...
Udi, Ok, I misunderstood. I thought that just a week or two ago it was the case. Perhaps it wasn't you but someone else who misapplied your blog. Vaughn...
Hey Nuno, You know what? I have been following this group for some time and it is interesting how some folks react to different ideas. Now I am a native...
Hi Vaughn, It actually was someone else. I also forget but that person used it to persist *to* the repository. I just thought about using it to read....
Hi Eben, Sounds like the bit you need from an ORM is the lazy loading, and the bit you don't like from an ORM is the mapping stuff? How about rolling your own...
Hi Eben Try a prefetch strategy. Something like: Order aOrder = Orders.GetOrderToBill(orderId); aOrder.MakeBill(); Greg, Your approach to persistence is smart...
Hi Dan, Thanks for the input. If you go back to around Feb/Mar 2008 I mentioned using proxies for lazy-loading and got somewhat of a roasting. But the idea is...
Hey Nuno, That is typically what I would do :) What I have been experimenting with is having my UnitOfWork keep a list of entity types required in the use...
... But at least the DBAs would have full visibility and could help ensure backwards compatibility if the underlying database tables change for some other...
At work now so I can't give a long reply. The one thing I don't see is how any system can be proven to be correct if the developers make mistakes? I mean yes I...
Not sure how much positive input you are bringing? If you have different AR's for different contexts then they should be persisted individually from each...
Hey Mark, ... if you want to split the behaviour into different implementations of your AR (this seems very weird to me, but this is what I understand for your...
hey Mark - thanks - does that not start to get really confused if the aggregate root now has to figure out which child entity to pass events to? 2009/10/30...
Ahh ok, well you would of course have the different AR types, not everything is in one type. Well these two command have their own command handler which knows...
I am thinking you could just fire them to each and the child has a handler or not, or you can have the AR have specific handlers for each event and some of...
I've totally bought into the advantages of separating your command and read queries to enable you to scale out reads (amongst other things). However, I'm still...
Hey Mark, Thanks for that. Now: -> Loads the correct Customer using the AR Id from the command. -> Loads the correct Order using the AR Id from the command. So...
I think what Eben was talking about having different AR's but use them differently in different use cases. I don't think he meant Customer1 AR for usecase 1...
