Это правильный подход к проектированию N-слоев? - PullRequest
Новая
       6

Это правильный подход к проектированию N-слоев?

2 голосов
/ 23 января 2012

Я планирую создать разные слои, поэтому в моем проекте Visual Studio у меня будет:

BusinessLayer: содержит бизнес-объекты (сущности), т.е. пользователя, сотрудника, продукты и т. Д.

DataAccessLayer: Entity Framework

Уровни представления: Views & ViewModels

Так, например, я хочу разрешить вход пользователя в это приложение.

  1. В представлении отобразитсяПользовательский интерфейс, позволяющий пользователю вводить информацию.
  2. Когда пользователь нажимает ввод, выполните команду => ViewModel
  3. ViewModel будет использовать Entity Framework для запроса данных пользователя из базы данных, затем ViewModel инициализирует объект User.(из BusinessObject) и сопоставляет данные пользователя с объектом пользователя.
  4. Этот объект пользователя затем будет сохранен в статическом параметре для будущего использования.

Итак, что меня действительно беспокоит, так это:

  1. Это правильный способ создания N-слоев?
  2. Должен ли я разделить каждый слой на другой проект Visual Studio?(т. е. бизнес-объекты будут находиться внутри другого проекта)
  3. Лучше ли позволить бизнес-объектам самостоятельно запрашивать данные?Таким образом, в Business Object construtor будет вызывать структуру сущностей?
  4. Должен ли я написать класс репозитория для использования инфраструктуры сущностей?

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

Любой совет будет отличным, спасибо.

1 Ответ

2 голосов
/ 23 января 2012

1 Это правильный способ создания N-слоев?

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

2 Должен ли я разделить каждый слой на другой проект Visual Studio?(т. е. бизнес-объекты будут находиться внутри другого проекта)

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

Учтите, что при выборе отдельных проектов архитектура становится более сложной, но также более масштабируемой.Например, вы можете предоставить пользователям отдельное исправление patch Business Layer и не устанавливать весь пакет программного обеспечения.Я повторяю, это выбор.В большинстве случаев они просто выбирают установку всего за один раз, чтобы избежать сложности (управление зависимостями, управление версиями между различными частями и весь этот беспорядок ...)

3 Лучше ли разрешить Business Object запрашиватьданные это самостоятельно?Так что в Business Object конструктор будет называть сущность каркаса?

Лучше было бы разделить Query движок.Более тестируемая и масштабируемая архитектура.

4 Должен ли я написать класс репозитория для использования инфраструктуры объектов?

Опять рассказ о масштабируемости.Вы можете обернуть EF, в этом случае у вас будет возможность в один день, когда вы решите включить (скажем) SQLite + ORM, внести в него изменения, не нарушая всю программную инфраструктуру (насколько это возможно, естественно).Но учтите, что на реализацию этого вам нужно гораздо больше времени.

Сбалансируйте свои ресурсы и время и сделайте выбор более подходящим для вас и вашего проекта.

...