Где должны находиться доменные объекты и объекты класса обслуживания? - PullRequest
Новая
       0

Где должны находиться доменные объекты и объекты класса обслуживания?

2 голосов
/ 08 июня 2011

Я делаю все возможное, чтобы выучить DDD, но я не уверен в некоторых действительно базовых концепциях;Где расположены ваши доменные объекты и сервисы, и как организован общий макет?У меня есть привычка, хорошая или плохая, я не знаю, вот почему я спрашиваю;создать «программный» класс, который содержит доменные коллекции, доменные объекты и сервисные объекты.Как пример ниже.

Это хороший или плохой подход?И если плохо, каковы альтернативы?Пока что я просто работаю с проектами winforms, поэтому это моя главная забота в настоящее время.

Кроме того, не могли бы вы немного оценить мое использование "статических" объектов здесь?Я часто не уверен, стоит ли использовать static, и склоняюсь просто включить его, если я знаю, что это одноэлементный объект (если это правильный термин).

РЕДАКТИРОВАТЬ: Чтобы объяснить немного больше, я использую метод New класса "Program" для координации различных объектов домена и запуска начальной загрузкииз базы данных и т. д. при запуске программы.Так что, если вы предлагаете мне избавиться от этого класса, то стоит ли мне предлагать какие-то другие сервисы вместо запуска программы?

Пример: 

class Form1
{
    private MainClass main;
}

class MainClass
{
    public static UserService UserServ;
    public static UserAccountService UserAccServ;
    public static List<UserAccount> UserAccounts; 
}

class UserService
{
}

class UserAccountService
{
}

class UserAccount
{
    public UserData User;
}

class UserData
{
}

РЕДАКТИРОВАТЬ: Ответ Дэвиду:

Спасибо!Чтобы ответить на ваши вопросы:

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

2) Разобрались с советами по интерфейсам.

3) Разобрался с ассемблерами.

4) Я использую репозитории (и FluentNHibernate), я планирую, чтобы службы зависели от них, да.На данный момент у меня есть классы xxxManager, которые, как я знаю, плохи, и я буду работать над их заменой на xxxServices.

5) Я понимаю, что DI очень популярен, и хорошо, что вы сделали это, так что я знаю, что это ключевое решение для моего вопроса.Я буду учиться этому.Итак, насколько я понимаю, вы предлагаете мне внедрить сервисы непосредственно в класс формы?Но как насчет доменных объектов?Где они живут"?Должны ли они все жить в каком-то типе услуг?Если это так, какой тип служб вы создаете для работы с логикой запуска программы?Я понимаю основные концепции служб для сохранения данных, использования репозиториев и т. Д., Но, вероятно, есть другой тип общих классов служб, о которых я не знаю, связанных с моим вопросом?

PS: Iне должен был (по ошибке) назвать мой класс "Программой", так как это уже класс в проектах C #.Я использую как C #, так и VB, поэтому на самом деле в C # я обычно называю это MainClass.Поэтому я отредактировал это.

1 Ответ

1 голос
/ 08 июня 2011

То, что вы описываете, это как организовать ваши зависимости (в данном случае ваш проект форм зависит от сервисов).

Несколько замечаний оКод выше:

  • Похоже, у вас все ваши классы в одном файле.Как правило, каждый новый класс следует помещать в отдельный файл.
  • Ваши классы обслуживания должны одновременно реализовывать и interface (IUserService и IUserAccountService) - это позволяет вам высмеивать вашзависимости для модульных тестов, для замены реализаций и для лучшего разделения вашего приложения.
  • В идеале ваши классы обслуживания должны быть в другой сборке (новый проект Visual Studio), как и ваши доменные сущности (UserAccount и * 1020).*).
  • Вы можете рассмотреть возможность создания одного или нескольких репозиториев, чтобы иметь дело просто с передачей данных в ваши сервисы приложений (сервисы приложений будут зависеть от репозитория, репозиторий будет не зависетьв службе).
  • Ваши службы работают в статических полях (а не в одноэлементном, это шаблон, который использует статические поля в C #, чтобы гарантировать, что для жизни приложения будет создан ровно один объект).Было бы лучше, если бы вы использовали DI (см. Ниже) вместо форм, используя Program.UserService ... и т. Д.

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

...