2010-06-07 2 views
6

Как я узнал о разработке программного обеспечения последние 2 года, чем больше я изучаю, тем больше серых областей, в которые я сталкиваюсь. Одна из серых областей, с которыми я сейчас сталкиваюсь, пытается решить, сколько слоев должно иметь приложение. Например, в WPF MVVM-приложении, какая форма расслоения в порядке? Является ли следующее разделение? Когда я упоминаю о расслоении, я имею в виду создание новой библиотеки классов для каждого слоя.Сколько слоев слишком много?

  • Представление (View)
  • View Model
  • Business Layer
  • Доступ к данным
  • Модель Layer
  • Utility Layer

Или для не применения MVVM это слишком отделенный?

  • Presenation
  • Бизнес
  • Доступ к данным
  • Модель Layer
  • Utility Layer

Является ли приемлемым для запуска слои вместе и просто создавать папки для каждого слоя? Любая окраска этой серой зоны была бы оценена.

+1

Другой вопрос, который вы можете задать себе: сколько слоев слишком мало? –

+1

Сообщество Wiki? На этот вопрос нет «правильного» ответа ... как это для серой области? :) –

+9

Ответ, конечно, 42 –

ответ

1

Layered Architecture: В данной статье описывается конкретная архитектура примера для Rich Client Applications .NET/WPF. Кроме того, архитектура показывает, на каком слое вы находите участников шаблона Model-View-ViewModel (MVVM).

2

Ответ, это зависит. Во-первых, отдельная библиотека классов не всегда означает отдельный «слой». Слой представляет собой концептуальную группировку связанных функций, которые могут или не могут проявляться в одной сборке.

Сколько слоев, которые вы создаете, действительно зависит от вашей проблемы. Традиционно приложение WPF MVVM будет содержать как минимум 3 слоя (Model, View, View Model), но это действительно может быть изменено. Часто я вижу Views и ViewModels в той же сборке и моделях в своей собственной сборке (обычно потому, что объекты модели являются POCO, которые используются в других контекстах)

На самом деле нет серебряной пули, которая отвечает на ваш вопрос, это полностью зависит от вашей проблемы. Преимущество «расслоения» и разделения заключается в увеличении ремонтопригодности, продвижении повторного использования кода и увеличении общей ясности (чтобы назвать несколько).

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

Суть заключается в том, чтобы не конструировать что-то ради соблюдения строгой «картины». Если у шаблона есть явные преимущества для вас и вашей проблемы, тогда реализуйте его, но поймите, почему вы это делаете и какова цель каждого «слоя».

2

Рассмотрим следующие области:.

  • Скорость
  • Повторное использование
  • читаемость
  • Время разработки
  • скорость
  • Модификация (правильные слова, чтобы описать эту точку спасаясь меня Edit - ремонтопригодность было что я искал [украл у кого-то elses ответ])
  • Область применения (масштаб и l iteral размер)
  • Ваша команда разработчиков

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

1

Приложение имеет слишком много слоев, если сами слои становятся препятствием для ремонтопригодности проекта, а не улучшения ремонтопригодности.

+0

На практике мои системы всегда состоят из: 'front proxy' всего, что принимает запросы пользователей, такие как MVC-контроллер; 'business' это обрабатывает оркестровку * последовательности * в действии; 'compute' обрабатывает всю алгоритмическую работу, агрегацию данных и т. д .; и «доступ к данным», который обрабатывает все вызовы sql, удаленные веб-запросы, файловую систему и т. д. –

1

Точное количество слоев, которое слишком много, составляет 1 больше, чем необходимо.