Как предоставить доступ к спискам объектов, которые входят в составной корень? - PullRequest
0 голосов
/ 18 ноября 2011

Если у меня есть сводный корень, который состоит из:

class Parent
{
    IEnumerable<Child> Children{ get; set; }
}

Дочерние объекты могут содержать любое количество возможных дочерних объектов, которые хранятся в базе данных.

Что было бы лучшеспособ получения полного списка всех дочерних объектов в приложении, чтобы они могли быть представлены в пользовательском интерфейсе, позволяющем пользователю присоединять / удалять их из родительского объекта?

Наличие метода в родительском объекте, например

class Parent
{
    IEnumerable<Children> GetAllChildObjects { get; set; }
}

наверняка испортило бы модель с деталями реализации?

Было бы нормально иметь доменную службу, которая вызывает родительский репозиторий и получает полный список.Фасад приложения может затем вызывать сервис напрямую, гарантируя, что родительская модель остается «чистой».

Обновление:

Чтобы дать немного больше деталей, я приведу систему в порядок ипытаясь придать ему некоторую структуру.

Пользователь может содержать несколько рабочих мест.WorkLocations довольно просты.Текущая система содержит веб-страницу, которая отображает данные пользователя, включая полный список действительных рабочих мест.Выбор местоположений из списка обновляет модель пользователя новыми местоположениями.

В настоящее время пользовательский интерфейс в значительной степени попадает в БД и вытаскивает полный список рабочих мест.Мне нужно перенести это обратно в более структурированную форму.

Или это предполагает, что WorkLocation не должен быть в корне пользователя, как в настоящее время?

Ответы [ 2 ]

1 голос
/ 18 ноября 2011

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

Если так, я бы определенно выбрал сервисный подход, что-то вроде:

public interface IWorkLocationsService
{
    IEnumerable<WorkLocation> GetAllWorkLocations();
}

Возможно, вы захотите, чтобы WorkLocation был неизменным, чтобы все изменения в нем проходили через пользователя, хотя я подозреваю, что в этом нет необходимости.

Обновление:

Затем можно добавить следующие методы к User

// This gets filled from the db somehow.
private IList<WorkLocation> workLocations;

// IEnumerable so that all external additions and
// removals must go through dedicated methods.
public IEnumerable<WorkLocation> WorkLocations
{
    get { return workLocations; }
}

public void AddWorkLocation(WorkLocation locationToAdd)
{
    workLocations.Add(locationToAdd);
    // Do whatever else you need to, i.e. mark the item for saving.
}

public void RemoveWorkLocation(WorkLocation locationToRemove)
{
    workLocations.Remove(locationToRemove);
    // Do whatever else you need to, i.e. mark the item for saving.
}
1 голос
/ 18 ноября 2011

Если вам действительно необходимо получить список SonOfFoo по какой-то причине, используя простые высокоуровневые интерфейсы, такие как IEnumerable, вы не повредите модель деталями реализации.

В зависимости от того, что вам нужно сделать, было бы лучше избегать получения списка SonOfFoo, хотя было бы лучше, если бы Foo управлял работой.

Также в зависимости от количества деталей, которые есть у SonOfFoo, было бы неплохо инкапсулировать его в интерфейс с методами, которые должен будет использовать пользовательский интерфейс / фасад.

Edit:

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

...