Структура проекта приложения Silverlight - Сколько это слишком много? - PullRequest
Новая
       6

Структура проекта приложения Silverlight - Сколько это слишком много?

1 голос
/ 29 сентября 2010

Моя команда работает над созданием нашего первого приложения Silverlight 4. Прежде всего, дать немного подробностей о реальном проекте. Это будет Silverlight 4, предназначенный для запуска Out-oF-Browser, и мы будем использовать WFC для служб данных с нашей собственной реализацией Dataobjects. (НЕТ структуры сущностей, LINQ-to-SQL и т. Д.). У нас есть несколько консультантов, которые рекомендуют структуру решения, которая содержит более 11 отдельных проектов. Нам кажется, что это просто не является причиной, может кто-нибудь увидеть какое-либо обоснование того, почему может потребоваться что-то вроде следующего?

  • Project.Client - активы, стили, представления
  • Project.Common - Конвертеры, Помощники
  • Project.Data - Неизвестная цель (клиентский проект)
  • Project.Infrastructure - команды, константы, интерфейсы, ведение журнала
  • Project.MajorFunctionA - «Бизнес-логика для основной функции A приложения»
  • Project.MajorFunctionB - «Бизнес-логика для основной функции A приложения»
  • Project.MajorFunctionC - «Бизнес-логика для основной функции A приложения»
  • Project.Models - Абстрактный доступ к службам WCF
  • Project.UIControls - пользовательские элементы управления для пользовательского интерфейса
  • Project.UnitTests - «Потенциально все модульные тесты»
  • Project.ViewModels - просмотр моделей для пользовательского интерфейса
  • Project.Web - хост-проект для приложения silverlight - без кода
  • Project.Web.Infrastructure - объекты данных и службы WCF

Теперь, наша главная путаница связана с тем, что мы не просто выделяем пространство имен, чтобы разделить их, а также такие вещи, как «Project.MajorFunctionA», который является лишь небольшим компонентом приложения, почему оно должно иметь свое проект. (Имейте в виду, что Views и ViewModel для этой конкретной функции НЕ будут жить в этом проекте, а в других проектах Client / ViewModel.

Мы просто ищем подтверждение, поскольку я не вижу в этом никакой причины.

1 Ответ

3 голосов
/ 30 сентября 2010

Согласовано: использовать пространства имен для логической организации, а не проектов.Один из подходов - думать о проектах как о единицах развертывания.Будет ли Project.Client всегда развертываться с Project.ViewModels?Project.Models?Один ссылается на другой?Просто включите в тот же проект и используйте пространства имен для организации.

Несколько причин, по которым вам может потребоваться разделить библиотеки / приложения классов Silverlight на отдельные проекты:

  • Повторное использование.Вы хотите разработать API, которые будут использоваться для других приложений.Ваша Project.Infrastructure может попасть в эту категорию.
  • Модульность.MajorFunctionA используется только конечным пользователем в 20% случаев.Возможно, только определенные аутентифицированные пользователи имеют доступ.Может быть, это только доступ при переходе на определенную страницу, на которую никто не заходит.Вы можете встроить отдельные приложения Silverlight и загружать файлы .xaps только при необходимости, используя такие среды, как MEF или PRISM.
  • Рабочие процессы разработчика.Одна команда в одном городе / офисе работает над Project.Client, а другая команда в другом городе / офисе работает над Project.Models.Возможно, имеет смысл встроить отдельные проекты, чтобы упростить жизнь.

Еще одна вещь, которую следует отметить при сборке, это то, что между сборками не может быть циклических ссылок.Другими словами, если ClassA и ClassB находятся в одной сборке, ClassA может ссылаться на ClassB, а ClassB может ссылаться на ClassA.Но если они находятся в отдельных сборках, они не могут.Теперь, если у ваших классов много циклических ссылок, это, вероятно, не очень хорошая вещь, но иногда этого трудно избежать, и ваши варианты намного более ограничены, если они оказываются в отдельных сборках.Но, с другой стороны, увеличение количества сборок ограничивает возможность циклических ссылок, которые могут улучшить качество вашего дизайна.Просто еще кое-что, о чем следует знать.

Следуя этой логике, одной из альтернатив будет группировка Project.Client, Project.Data, Project.Model, Project.UIControls и Project.ViewModels в одном проекте и группировка Project.Общее и Project.Infrastructure в другое.Основные функции могут быть оставлены отдельно или сгруппированы в Project.Client.В итоге вы получите:

  • Project.Client - интерфейс для конкретного приложения, просмотр моделей и моделей.
  • Project.Infrastructure - общие, многократно используемые помощники, конвертеры и интерфейсы.
  • Project.UnitTests
  • Project.Web
  • Project.Web.Infrastructure

Также.Там нет действительно правильный ответ для этого.Я отмечаю как Сообщество Wiki.

...