Какова наилучшая практика для проектирования уровня обслуживания, когда бизнес-данные имеют отношение от 1 до 0..1? - PullRequest
Новая
       33

Какова наилучшая практика для проектирования уровня обслуживания, когда бизнес-данные имеют отношение от 1 до 0..1?

2 голосов
/ 29 марта 2011

Приветствую всех,

Я исследовал и нашел ряд дискуссий по проектированию уровня обслуживания MVC, но я не нашел ответа на свои точные вопросы.Пост о взаимозависимости уровня обслуживания содержит изображение, иллюстрирующее то, что я имею в виду, но у меня есть еще один вопрос, который, как мне кажется, не рассматривается в упомянутом посте.

Мое приложение будетотслеживать данные для некоммерческих организаций, которые взаимодействуют с людьми в разных контекстах.Может быть, человек был клиентом, может быть, они были советником, или, может быть, они были противником.Их может быть несколько.Позже клиент может стать противником (например, клиентами юристов).

Моя идея состоит в том, что создание нового клиента или нового противника всегда создает две записи: 1 запись в таблице персонажа и одна запись ввспомогательный столМои мысли за этим заключаются в том, что будет одно место (таблица лиц), чтобы проверить, имел ли бизнес какие-либо прошлые взаимодействия с данным человеком.

Мой вопрос заключается в том, чтобы при представлении сущностей в отношении от 1 до 0..1 на уровне контроллера (1) Должен ли контроллер участвовать в объединении и разделении классов перед передачей их в представление?(2) Если нет, должен ли сервисный уровень создавать модель представления?

Я читал пост о контроллере линии 1800 здесь .Я также прочитал этот пост , в котором говорится, что ваш сервисный уровень не должен знать о модели представления, что заставляет меня думать, что оно живет и умирает на уровне контроллера.Если сервисный уровень не касается модели представления, например, (3), будет ли правильным для workerService возвращать объекты Person и Worker в контроллер?

Вот мои классы сущностей: 

public class Record
{
    public DateTime datecreated { get; set; }
    public DateTime dateupdated { get; set; }
    public string Createdby { get; set; }
    public string Updatedby { get; set; }
}

public class Person : Record
{   
    public int ID { get; set; }
    public virtual Worker Worker { get; set; }
    publiv virtual Defendant defendant {get; set;}
    ...
}

public class Worker : Record
{
    public int ID { get; set; }
    public virtual Person person { get; set; }
    ...
}

public class Defendant : Record
{
    public int ID { get; set; }
    public virtual Person person { get; set; }
    ...
}

1 Ответ

1 голос
/ 29 марта 2011

Я думаю, вы должны попытаться найти баланс между тем, что "хороший дизайн" и что работает для вас.

Например, у меня есть приложение MVC, которое использует ASP.NET Membership, но у меня также есть пользовательская таблица User, в которой я храню такие вещи, как изящное имя пользователя или OpenID. В этом же приложении у меня есть IAdminService, который обрабатывает все, что касается администрирования пользователей.
IAdminService возвращает контроллеру класс AdminUser, который выглядит следующим образом: 

public class AdminUser
{
    public string UserName { get; set; }
    public User User { get; set; }
    public MembershipUserWrapper MembershipUser { get; set; }
}

MembershipUserWrapper - это просто оболочка вокруг значения по умолчанию MembershipUser, позволяющая проводить тестирование и обеспечивать большую гибкость в целом.

В любом случае, вы можете утверждать, что AdminUser на самом деле является моделью представления, и у меня действительно есть пара представлений, строго типизированных как AdminUser. Было бы излишне усложнять вопросы, чтобы не дать IAdminService вернуть AdminUser только потому, что он находится на «уровне обслуживания», и в этом случае вам не нужен контроллер, выполняющий «преобразование» из User и MembershipUserWrapper до AdminUser каждый раз.

Является ли правильным, чтобы работник workerService возвращал в Контроллер объекты Person и Worker?

Я думаю, что в этом случае это, вероятно, так. У вас может быть два отдельных сервиса, но большая часть логики для извлечения Worker и Person, вероятно, одинакова, поэтому вы будете вынуждены либо повторить много кода, либо создать третий сервис, который выполняет общие задачи.

Вы должны обратить внимание на правильное проектирование, но также принять во внимание K.I.S.S. и YAGNI . Делайте то, что имеет смысл сейчас, и при необходимости делайте рефакторинг соответственно.

...