Согласен с ChuckJ - как правило, DomainContext является частью модели представления. Например, скажем, у меня была страница поиска, которая позволяла искать по каталогу продуктов. Вот как я бы структурировал вещи:
На сервере:
class Catalog : DomainService {
IQueryable<Product> GetProducts(string keyword) { ... }
}
Сгенерированный DomainContext:
class Catalog : DomainContext {
EntityList<Product> Products { get; }
void LoadProducts(string keyword);
}
Вид модели, которую я написал бы:
class SearchViewModel {
Catalog _catalog = new Catalog();
public IEnumerable<Product> Results {
get { return _catalog.Products; }
}
public void Search(string keyword) {
_catalog.Products.Clear();
_catalog.LoadProducts(keyword);
}
}
И, наконец, в моем xaml я установил DataContext моего UserControl как экземпляр SearchViewModel и привязал ItemsControl к свойству Results. Я бы использовал шаблон ViewModel по вашему выбору, чтобы привязать нажатие кнопки к поиску (что фактически является командой, которую предоставляет SearchViewModel). Мне лично нравится то, с чем я работаю Silverlight.FX , например:
<Button Content="Search"
fxui:Interaction.ClickAction="$model.Search(keywordTextBox.Text)" />
и, как первоначально показано здесь .
Как упоминает Чак, у меня действительно может быть другое состояние в моей модели представления, например, SelectedProduct, который может быть двусторонне связан с SelectedItem объекта ListBox в моем xaml, а затем связать тот же SelectedProduct, что и DataContext объекта. DataForm для отображения сведений о выбранном продукте.
Надеюсь, это поможет! Об этом я скоро еще напишу в своем блоге 1024 *.