2016-06-27 3 views
0

Я создаю новое приложение UWP, используя Mvvm Light и Entity Framework Core. Я новичок в этих двух технологиях.Mvvm Light и Entity Framework Основные передовые методы

Я создаю свою модель: Статьи класса является простым ObservableObject с 3 свойствами: Id, Référence и ОБОЗНАЧЕНИЕМ.

Мои DbContext является следующее:

public class UniversalTest1Context : DbContext 
{ 
    public DbSet<Article> Articles { get; set; } 

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) 
    { 
     optionsBuilder.UseSqlite("Filename=UniversalTest1.db"); 
    } 

} 

Я ищу лучший способ управлять DbContext и мои разные взгляды.

Лучше ли создать один DbContext для всего приложения? Мне не очень нравится эта идея.

Должен ли я создать DbContext в каждой ViewModel? Мне больше нравится.
Когда пользователь дважды нажимает на элемент в представлении списка статей, я перехожу к подробному представлению статьи и передаю статью модели представления, связанной с представлением подробного описания статьи. Но эта уже существующая статья не связана с DbContext модели подробного представления статьи.

Возможно ли создать экземпляр DbContext только при необходимости? Моя предпочтительная опция.
Для этого я передаю статью из модели просмотра списка в модель детального просмотра. И тогда, когда пользователь щелкает сохранить исполняю что-то вроде этого:

using (var db = new UniversalTest1Context()) 
{ 
    db.Articles.Add(article); 
    await db.SaveChangesAsync(); 
} 

Конечно, это работает для новых статей (вставка), но не для уже существующих (обновление).

У меня возникли трудности с этим.

Большое спасибо заранее, Julien

+0

Я бы посмотрел CQRS и [Mediatr] (https://github.com/jbogard/MediatR). Вы должны создавать экземпляр каждый раз, когда используете его, потому что каждый экземпляр является единицей работы. –

+0

Каллум, в этом случае, как я могу передать статью, измененную на мой взгляд, на новый DbContext, чтобы ее можно было сохранить в базе данных? –

+0

Если вы читаете в MediatR, вы создаете так называемый «класс SaveArticleRequest: IRequest

». Затем он отправляется из MediatR с помощью 'mediator.SendAsync (new SaveArticleRequest (статья)); таким образом вы создаете только очень нишу (SRP), которые касаются одной вещи. Это означает, что вы можете составить свою систему с большой детализацией. ИМХО - удивительный образец. –

ответ

0

На мой взгляд, вы должны скрыть все хранящие операции через интерфейс (как IArticleRepo или то вроде этого), и вы должны использовать IoC для доступа к нему (если некоторый класс хочет работать с Store, он должен объявить IArticleRepo в параметрах ctor). Кроме того, внутри этого интерфейса IArticleRepo вы можете обрабатывать ненужные операции с помощью статей, таких как IArticleRepo.AddArticle (статья a). Если вы это сделаете, вы можете выбрать позже, хотите ли вы создавать dbcontext для каждой операции или нет ИЛИ, возможно, вы хотите сделать реализацию IArticleRepo как одиночную, используя контейнер IoC. Но такие решения не должны влиять на другой код. Как очень простой образец в моем коде (я показываю только этот файл, весь проект уродлив, и я его изменю) https://github.com/tym32167/arma3beclient/blob/master/src/Arma3BE.Client.Libs/Repositories/PlayerRepository.cs#L23

Смежные вопросы