StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POArchitecture for status managment
primarykey
Id
20037112
data
AcceptedAnswerId
20043066
AnswerCount
2
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-11-17T22:35:32.857
FavoriteCount
0
LastActivityDate
2013-11-18T09:22:55.887
LastEditDate
LastEditorUserId
0
OwnerUserId
2761509
ParentId
0
PostTypeId
1
Score
1
ViewCount
74
LastEditorDisplayName
text
Body
What I have: One-to-many relationship between A and B entities. Each of those entities have a status. There are a finit amount of statuses, about 7-12 for each. I have to check if the transition (from one status to another) is possible. And make few additional tasks on transition, like store history and make logging. Don't fall in delusion, status isn't equals to state. It isn't about <code>State Pattern</code> because my entities haven't any state-based logic. How does it happen: Entity arrives as a part of update request, and I compare if old version of entity has the same status as the new version. If not - the status has been changed. Status is just a string or enum. What I want: Of course, there are some rules, which impose restrictions on state transition. I want the next: <ol> <li>Transition verification. Means I want to check if the entity CAN be moved to the asked state. Example: <code>A-entity</code> can be moved to <code>Y-state</code> only if it is in <code>X-state</code> and all related <code>B-entities</code> are in <code>Z-state</code>. </li> <li>Automatical transition (not in all cases). Means the state of <code>A-entity</code> should always be consistent related to all linked <code>B-entities</code>. Example: If I move <code>B-entity</code> to <code>X-state</code> than related <code>A-entity</code> should be moved to 'Y-state'.</li> <li>Store history. Means which entity and when was moved to the state.</li> </ol> What a problem: The simples solution is to write a transition-matrix, where <code>matrix[i][j] == 1</code> if transition is possible and <code>0</code> otherwise. But there are some problems: <ol> <li>What about situation when the transition is depend not only on the state of updated entity? Matrix doesn't solve this problem.</li> <li>What about history and loging?</li> <li>How to avoid a lot of <code>if-statements</code>? </li> </ol> Question I'm looking for Pattern/Common Practice suitable for this situation. What is a patter/best practice of solving the task?
Tags
<design-patterns><architecture>
Title
Architecture for status managment
singulars
PostAcceptedAnswerId
1. PO
 singulars
 PostTypePostTypeId
 PTAnswer
PostParentId
1. This table or related slice is empty.
PostTypePostTypeId
1. PTQuestion
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USVB_
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. PO
 singulars
 PostTypePostTypeId
 PTAnswer
2. PO
 singulars
 PostTypePostTypeId
 PTAnswer
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 POArchitecture for status managment
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
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.