Разделение решений распределенных систем для реализации
Обновлен: Ноябрь 2007
Когда группы разработки готовы к реализации определений приложения на диаграмме приложения, поддерживающей реализацию, руководитель разработки может создать проекты для этих определений в Visual Studio. Эти проекты отображаются в обозревателе решений вместе с другими элементами в одном решении. Однако возможны случаи, когда решение потребуется разделить на меньшие решения. Создание небольших решений, содержащих только подмножество приложений, дает гибкие возможности организации проектов для разработки. Visual Studio позволяет включать проекты в любое число решений, так чтобы можно было создать решения, содержащие подмножество проектов. Кроме того, может оказаться полезным хранить исходное решение в качестве "главного" решения, что позволит согласовать изменения с исходным объемом решения, создавать системы и определять развертывание в этом объеме.
.gif "Примечание") Примечание. |
|---|
Методы и рекомендации, описанные в этом разделе, подразумевают использование системы управления версиями. Дополнительные сведения см. в разделе Документы модели определения системы (SDM) в системе управления версиями. При разделении решений рекомендуется использовать статические порты в приложениях ASP.NET на основе файловой системы, которые по умолчанию используют динамические порты. При использовании динамических портов в приложении ASP.NET число портов может измениться в любой из его веб-служб, что приведет к потере связей соответствующих веб-ссылок. Дополнительные сведения см. в разделе Общие сведения о приложениях ASP.NET на диаграммах приложений. |
Следующие подразделы содержат дополнительные сведения о разделении решений.
Решения, выделенные из главного решения
Сохранение исходного решения как главного решения
Обновление главного решения на основе изменений выделенных решений
Решения, выделенные из главного решения
В случаях, когда определения приложений для большой сложной системы приложений создаются в отдельном решении, лучшей управляемости можно добиться путем разделения решения на меньшие решения для реализации приложений. Каждое выделенное решение будет включать подмножество определений приложений и соответствующие им проекты, в том числе файлы кода, файлы конфигурации и файлы SDM, которые содержат сведения модели определения системы (SDM) для связанных определений приложений.
При разделении решения можно придерживаться различных стратегий. Например, если вся система состоит из четко разграниченных членов системы, решения можно создать на основе границ каждой системы в решении. В этом случае каждое решение будет включать проекты для определений приложений, на которые ссылается система. В зависимости от сложности каждой системы, такие выделенные решения можно будет дополнительно разделить на более мелкие решения. Кроме того, решения можно разделить до уровня отдельных разработчиков так, чтобы решение каждого разработчика включало только те части системы, за которые отвечает каждый разработчик. При помощи системы управления версиями можно организовать совместное использование проектов. При этом следует помнить о некоторых проблемах, сопряженных с совместным использованием проектов. Дополнительные сведения см. в разделе Одновременное извлечение и внесение изменений в документы модели определения системы (SDM).
| Примечание. |
|---|
Даже несмотря на то, что границы системы можно использовать как логическую основу для выделения определений приложений и их проектов из отдельного решения и разделения на меньшие решения, разделять решение именно таким способом не обязательно. В случаях, когда системы накладываются друг на друга (содержат экземпляры одного и того же определения системы), описанный подход не является очень действенным. |
Содержимое выделенных решений
К каждому выделенному решению можно добавить диаграмму приложения. При этом определения приложений на схеме будут основаны на файлах определения приложения (SDM) в проектах такого решения. После процесса разделения любые проекты, добавляемые к решению, подвергаются обратному разбору на диаграмме приложения, если требуется. Каждое выделенное решение может также включать любые диаграммы системы с тем, чтобы пользователи могли проанализировать системы с экземплярами этих определений. Например, диаграммы системы с общими ссылками на определение приложения могут быть включены в выделенное решение ради контекста. Если необходимо оценить развертывание или создать отчеты о развертывании, то можно использовать диаграмму приложения или добавить диаграммы систем к выделенному решению с помощью конструкторов распределенных систем. Если выделенные решения нужны только для целей разработки проекта, не обязательно, чтобы какие-либо диаграммы распределенных систем присутствовали в этих решениях.
| Примечание. |
|---|
Если при закрытой диаграмме приложения удалить файл SDM, то он будет создан повторно при следующем открытии диаграммы приложения в решении, содержащем этот проект. Однако этот восстановленный файл SDM содержит только сведения, которые можно восстановить из другого источника. Другие сведения, хранившиеся исключительно в удаленном файле SDM будут потеряны. Кроме того, это может привести к нарушению ссылок на связанное определение. Дополнительные сведения см. в разделе Устранение неполадок на диаграммах приложений. Если общее определение приложения отсутствует в выделенном решении, экземпляры этого определения на диаграммах системы в составе решения будут нарушены. Попытки определения или оценки развертывания систем, ссылающихся на отсутствующее определение приложения, не будут возможными или успешными. Дополнительные сведения см. в разделе Синхронизация документов модели определения системы (SDM). При добавлении каких-либо диаграмм систем в решении должна присутствовать диаграмма приложения. |
Сохранение исходного решения как главного решения
После разделения решения на меньшие решения исходное решение можно сохранить как "главное". Данный подход делает возможным просмотр и анализ всей системы время от времени. Более того, если главное решение существует и имеет свою собственную диаграмму приложения, требование к использованию диаграммы приложения в каждом выделенном решении не предъявляется.
| Примечание. |
|---|
Хранить или поддерживать главное решение не обязательно. Например, если границы системы можно четко выделить на основе соединений между веб-службами, то будет достаточно управлять каждым выделенным решением в отдельности и представить взаимодействие между ними как соединения с внешними веб-службами. Внешние веб-службы добавляются к диаграмме приложения автоматически в каждом выделенном решении, если веб-служба имеется ссылки в рамках решения. Дополнительные сведения см. в разделе Типы приложений и прототипы для определения приложений. При этом, если требуется разработать системы более высокого уровня, ссылающиеся на выделенные системы нижнего уровня, можно создать определения системы, включающие только необходимые определения системы нижнего уровня. Однако чтобы определить и оценить развертывание этих систем, следует убедиться, что решение содержит все приложения, на которые имеются ссылки. |
Допустим, что в группу разработчиков входят три разработчика, работающие над тремя отдельными решениями и каждое выделенное решение включает проекты, связанные с определениями приложений. Эти три решения являются частью более крупного выделенного решения, охватывающего границы отдельной системы приложений. Выделенное решение, в свою очередь, является одним из многих выделенных решений, описывающих другие системы приложений, которые составляют всю систему, существующую в объеме главного решения.
По мере работы группы разработчиков над выделенными решениями, они будут возвращать внесенные ими изменения в систему управления версиями. Руководитель разработки впоследствии может обновить главное решение из системы управления версиями путем извлечения соответствующих схем и файлов. При этом произойдет синхронизация файлов кода и конфигурации с соответствующими схемами. Дополнительные сведения см. в разделах Общие сведения о модели определения системы (SDM) и Связи между документами модели определения системы (SDM).
Обновление главного решения на основе изменений выделенных решений
Архитекторы решений, руководители по разработке и другие ответственные за архитектуру системы лица могут периодически обновлять главное решение на основе изменений, вносимых в выделенные решения. Это лицо может извлечь выделенное решение с проектами, распределенными между группами разработки, которые могут работать непосредственного над этими проектами в рамках выделенного решения или в рамках дополнительно выделенных решений.
Это полезно для анализа всей системы в случае внесения изменений в архитектуру, для оценки правильности развертывания системы и для передачи изменений между решениями. Периодическое обновление и анализ главного решения также важен, если решение содержит единственную диаграмму приложения для всех решений и является единственным местоположением, в котором находятся системы.
При открытии диаграммы приложения в главном решении после обновления его проектов из системы управления версиями, архитектор приложений или руководитель по разработке может оценить воздействие изменений на проекты, которые были внесены в схему. Чтобы увидеть точные изменения, архитектор или руководитель по разработке может оценить список возвращенных изменений или сравнить различия в файлах кода. Архитектор или руководитель по разработке может синхронизировать диаграмму приложения в коде проекта или устранить любые предупреждения синхронизации путем извлечения необходимых проектов так, чтобы изменения, которые требуется внести, можно было передать в определения приложений и их экземпляры в определениях системы.
Если архитектор или руководитель по разработке принимает изменения, внесенные в эти проекты, их можно будет вернуть в решение. В противном случае, архитектор или руководитель по разработке должен совместно с группами разработки устранить любые конфликты так, чтобы код можно было синхронизировать со схемой.
См. также
Задачи
Практическое руководство. Разрешение конфликтов в документах модели определения системы (SDM)
Ссылки
Одновременное извлечение и внесение изменений в документы модели определения системы (SDM)