|
As you can see, creating a StaffingResource involves fetching additional data from the data source. In this case the primary address and phone types. Entities should never go out themselves and fetch additional data. That's a really bad practice. Even accessing a navigation property from within an entity should be avoided for two reasons. In Silverlight, navigations are always asynchronous, so the data you are trying to access may not be in the cache. You are making assumptions at that point about the current state of the cache in a place where you have no control over it. That almost always blows up in your face eventually. In WPF it leads to hidden n+1 problems, because navigation is synchronous by default. It will block your UI thread and pretty soon lead to horrible performance.Fetching data is the responsiblitiy of a repository, so if anything, an entity would need to get a hold of an appropriate repository, but that would create a reverse-dependency to a higher level, yet another bad practice. Repositories centeralize your query and fetch strategies and should be the only objects in your application that perform queries and fetch data. At the next higher level you have services that implement your business logic and orchestrate the repositories, fetching or creating all the necessary data for the particular business process. Entities are just chess figures that are moved around by these services to accomplish a certain goal. You might find the overview in the following thread helpful, about 7 posts down. http://www.ideablade.com/forum/forum_posts.asp?TID=3363&title=cocktail-v05-is-available-for-download - http://www.ideablade.com/forum/forum_posts.asp?TID=3363&title=cocktail-v05-is-available-for-download
|