StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
4034057
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2010-10-27T13:59:09.443
FavoriteCount
0
LastActivityDate
2010-10-27T14:27:29.710
LastEditDate
2010-10-27T14:27:29.710
LastEditorUserId
460932
OwnerUserId
460932
ParentId
4033600
PostTypeId
2
Score
10
ViewCount
0
LastEditorDisplayName
text
Body
Instead of implementing the first constructor, I suggest you implement a ViewModelLocator, like this: <pre><code>public class ViewModelLocator { IoCContainer Container { get; set; } public IUserViewModel UserViewModel { get { return IoCContainer.Resolve<IUserViewModel>(); } } } </code></pre> Then in XAML you declare the locator as a static resource: <pre><code><local:ViewModelLocator x:Key="ViewModelLocator"/> </code></pre> While you initialize your application, it is necessary to provide the locator with the instance of the container: <pre><code>var viewModelLocator = Application.Current.Resources["ViewModelLocator"] as ViewModelLocator; if(viewModelLocator == null) { // throw exception here } viewModelLocator.Container = IoCContainer; </code></pre> Then in XAML you can use the resource cleanly: <pre><code><UserControl DataContext="{Binding Path=UserViewModel, Source={StaticResource ViewModelLocator}}" />  </code></pre> For design time, you can implement a MockViewModelLocator: <pre><code>public class MockViewModelLocator { public IUserViewModel UserViewModel { get { return new MockUserViewModel(); } } } </code></pre> Declare it in XAML appropriately: <pre><code><local:MockViewModelLocator x:Key="MockViewModelLocator"/> </code></pre> And finally use it in your user control: <pre><code><UserControl d:DataContext="{Binding Path=UserViewModel, Source={StaticResource MockViewModelLocator}}" DataContext="{Binding Path=UserViewModel, Source={StaticResource ViewModelLocator}}" />  </code></pre> You can make your mock view model locator return safe and easily readable data for Blend to use and during runtime you will be using your real service. This way you do not lose design time data and you do not have to sacrifice the cleanliness of the dependency injection methodology in your view models. I hope this helps.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POSilverlight Constructor Injection into View Model + Design Mode
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USMurven
UserOwnerUserId
1. USMurven
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POSilverlight Constructor Injection into View Model + Design Mode
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COThanks for the detailed reply!
 singulars
 PostPostId
 PO
 UserUserId
 USJammin

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.