StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
15614164
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-03-25T11:47:04.467
FavoriteCount
0
LastActivityDate
2013-03-25T11:47:04.467
LastEditDate
LastEditorUserId
0
OwnerUserId
281177
ParentId
14560291
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
I think the general concept would be to have "Commands" and "Queries", and within those you can take dependencies on Repositories. I have actually refactored an ASP.NET MVC project where each Controller depended on one or more repositories to get it's work done. When I refactored it, I created "Command" and "Query" objects for each specific action that needed to happen which greatly simplified each controller. Then in those commands and queries I used the existing repositories to perform the logic. It may seem like extra effort, but the reason I did it was because the solution also had caching. The caching code was a mess, there were cache keys being added to and removed from all over the place. By separating all data access into commands and queries, then raising domain events when data was accessed or updated the cache management code could be simplified and separated out. For an overview of how I implement a simple command/query separation please see my recent blog post on the topic which also has sample code and NuGet packages to help you get setup quicker: <a href="http://www.nootn.com.au/2013/03/command-query-separation-to-better.html" rel="nofollow">http://www.nootn.com.au/2013/03/command-query-separation-to-better.html</a> In particular to answer your question "What happens when there is some common Read requirement across all business objects": just imagine that the Query and Command classes I have there take some common "IRepository" dependency instead of a "DBContext" as my example does and that is how you can "share" that common read requirement across business objects.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POIs this how CQRS is implemented with DI and Repository pattern?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USnootn
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.