2017-02-20 105 views
0

Я создаю многоуровневое приложение в .Net/C#/EF6/WPF/WCF.Где управлять изменением состояния объекта в многоуровневом приложении?

Бэкэнд - это база данных mysql с уровнем структуры сущности для доступа к базе данных. У меня есть уровень бизнес-логики и фасадный слой, чтобы открыть службу.

На стороне клиента клиент WPF/MVVM.

У меня есть 3 модели, одна для клиента («view domain»), одна для бэкэнд, созданная инфраструктурой сущности («домен db») и dto-like для сервисов.

На стороне клиента я отслеживаю изменения состояния объекта, в основном копирую EntityState перечисление с System.Data и устанавливая состояние при изменении свойства или при создании нового объекта.

Например, одна из моих услуг выставляет Add(Entity e) и Update(Entity e).

Должен ли я принимать решение назвать тот или иной метод на клиенте (он знает, что если состояние Added или Modified), или я должен выставить один метод, называемый AddOrUpdate(Entity e) и пусть бэкенд решить, если это новое или обновить объект ?

Каков наилучший подход для этого? Должен ли я принять решение на стороне клиента или стороне по этому поводу?

+0

, если у вас многоуровневое приложение и есть уровень доступа к данным вы должны проверять и контролировать состояние строк на уровне доступа к данным, но в entityframwork вам не нужно контролировать состояние объекта (например, состояние набора данных), и вы можете вызывать сохранение изменений для фиксации всех изменений, но если вам нужно управлять состояние, которым вы можете управлять им в фасадном пространстве, а затем решить, какой метод доступа к данным или правило больше всего назовешь. –

+1

Для меня более важным вопросом является вопрос о том, должен ли клиент вообще отслеживать изменения. Технически, клиент всегда имеет устаревшие данные, поэтому каждая точка данных потенциально «модифицирована», даже если клиент этого не знает. Только сервер предназначен для сравнения текущего состояния. Кроме того, служба не может доверять каждому клиенту, чтобы сделать это правильно, поэтому всегда нужно проверять/проверять изменения в любом случае. –

+0

У вас есть два способа нормально контролировать состояние 1.Вы можете управлять состоянием в фасаде, а затем, если вам нужно вызвать уровень правил и правило, вызовите уровень доступа к данным, и если вам нужно вернуть ошибку в презентационный уровень, вам не нужно идти на уровень правил или данных ... 2. другой способ вы можете использовать http-модуль для проверки такой ситуации. в этом случае у вас нет поддельного вызова службы ... –

ответ

1

Не знаете, почему вы хотите, чтобы клиент знал/обрабатывал состояние объекта.
Ваша проблема, вероятно, вызвана тем, что вы повторно используете класс «Entity» в обоих методах.

Я думаю, что вы можете использовать что-то вроде этого:

Add(InputResource e) 
Update(UpdateResource e) 

Ни одно из вышеперечисленного не должен иметь «State» собственности *.
«InputResource» не должен иметь идентификатор/первичный ключ

Я думаю, что вышеупомянутый подход более чист, но это зависит от ваших потребностей.
Если вы хотите пойти с «AddOrUpdate», я до сих пор не думаю, что добавление государства - хорошая идея.
Вы можете проверить свойство Id, если оно установлено, это обновление, если оно не является добавлением

* Конечно, я говорю о вашем публичном API.
Внутренне, на вашем сервере (BusinessLayer-DataLayer) у вас может быть решение, которое обрабатывает элементы в зависимости от их состояния, но я не думаю, что вы принимаете это