Философия подхода к реализации
подход к водопаду
Водопадный подход к реализации приложения требует, чтобы разработчик проконсультировался с одним или несколькими представителями организации конечного пользователя и записал все спецификации приложения. Как правило, спецификации представляют собой набор функциональных документов или вариантов использования, написанных таким образом, чтобы конечный пользователь мог легко читать и понимать документы.
Конечный пользователь подписывает эти документы, а затем документы собираются группой технического проектирования, которая разрабатывает приложение, создавая различные артефакты, такие как диаграммы моделей классов, диаграммы состояний, диаграммы действий и модели данных. Цель этого этапа — написать все так подробно, чтобы у разработчика не возникло проблем с созданием необходимого кода. Происходит официальная передача проекта команде разработчиков и команде тестирования. После доставки команда разработчиков начинает кодирование, а группа тестирования использует технический дизайн в сочетании с вариантами использования для создания тестовых случаев и тестовых сценариев.
После того, как команда разработчиков заканчивает писать код, код передается команде тестирования. Группа тестирования выполняет разработанные ею тесты на основе требований и подробного проекта. Любые проблемы будут устранены командой разработчиков. После завершения процесса тестирования и исправления приложение доставляется конечному пользователю для приемочного тестирования. Конечный пользователь выполняет окончательную проверку, чтобы убедиться, что приложение соответствует первоначальным требованиям. В случае одобрения он утверждает готовый продукт, и проект завершается. После того, как команда разработчиков заканчивает писать код, код передается команде тестирования.
Группа тестирования выполняет разработанные ею тесты на основе требований и подробного проекта. Любые проблемы будут устранены командой разработчиков. После завершения процесса тестирования и исправления приложение доставляется конечному пользователю для приемочного тестирования. Конечный пользователь выполняет окончательную проверку, чтобы убедиться, что приложение соответствует первоначальным требованиям. В случае одобрения он утверждает готовый продукт, и проект завершается. После того, как команда разработчиков заканчивает писать код, код передается команде тестирования. Группа тестирования выполняет разработанные ею тесты на основе требований и подробного проекта.
Любые проблемы будут устранены командой разработчиков. После завершения процесса тестирования и исправления приложение доставляется конечному пользователю для приемочного тестирования. Конечный пользователь выполняет окончательную проверку, чтобы убедиться, что приложение соответствует первоначальным требованиям. В случае одобрения он утверждает готовый продукт, и проект завершается.
Конечный пользователь выполняет окончательную проверку, чтобы убедиться, что приложение соответствует первоначальным требованиям. В случае одобрения он утверждает готовый продукт, и проект завершается. Конечный пользователь выполняет окончательную проверку, чтобы убедиться, что приложение соответствует первоначальным требованиям. В случае одобрения он утверждает готовый продукт, и проект завершается.
Проект может иметь больше или меньше фаз при использовании водопадного подхода, но ключевой особенностью является очень формальное начало и конец каждой фазы с очень формальными результатами.
Преимущество каскадного подхода в том, что ответственность команды, ответственной за каждый этап, выше. Понятно, что им нужно доставить, когда нужно доставить и кому нужно доставить. Часто команде разработчиков не нужно взаимодействовать с пользователем. Это может быть очень полезно при аутсорсинге разработки в другой стране.
Главный недостаток водопадного подхода заключается в том, что в среде, где все организовано очень формально, снижается гибкость реагирования на изменения. Даже переезд должен быть организован. Очень немногие компании делают это эффективно, что часто приводит к значительному увеличению накладных расходов. Чтобы управлять затратами на проект, некоторые компании даже откладывают любые изменения требований до первоначальной доставки приложения, фактически предоставляя приложение, которое не соответствует потребностям конечного пользователя.
гибкая разработка
Многие долгосрочные проекты по разработке программного обеспечения превышали бюджет и не доставляли продукт вовремя. Предпосылкой гибкой философии разработки программного обеспечения является минимизация риска путем разработки программного обеспечения в короткие сроки, называемые итерациями, которые обычно длятся от одной до четырех недель. Каждая итерация подобна собственному миниатюрному программному проекту и включает в себя все задачи, необходимые для выпуска приращения новой функциональности: планирование, анализ требований, дизайн, кодирование, тестирование и документирование. В то время как итерация может не добавить достаточно функциональности, чтобы гарантировать выпуск продукта, проект гибкого программного обеспечения направлен на то, чтобы иметь возможность выпускать новое программное обеспечение в конце каждой итерации. В конце каждой итерации команда переоценивает приоритеты проекта.
Цель гибкой разработки программного обеспечения — добиться удовлетворенности клиентов за счет быстрой и непрерывной поставки полезного программного обеспечения; всегда стремясь построить то, что нужно клиенту; приветствовать, а не противодействовать поздним изменениям требований; регулярно адаптироваться к меняющимся обстоятельствам; иметь тесное и ежедневное сотрудничество между предпринимателями и разработчиками, в котором беседа лицом к лицу является лучшей формой общения.
Основным преимуществом гибкой разработки программного обеспечения является гибкость в отношении изменений, всегда направленная на достижение результатов в соответствии с потребностями бизнеса. Обратной стороной, конечно же, является увеличение сложности управления объемом, планированием и составлением бюджета. Другим распространенным риском является ограниченное внимание к (технической) документации.
Инкрементальная разработка
Инкрементальная разработка программного обеспечения представляет собой сочетание гибкой и каскадной разработки. Приложение разрабатывается, внедряется и тестируется поэтапно, чтобы каждое дополнение могло быть доставлено конечному пользователю. Проект не завершен, пока не завершен последний шаг. Он направлен на сокращение каскада за счет определения промежуточных приращений и использования некоторых преимуществ гибкой разработки. На основе отзывов, полученных по предыдущему приращению, можно внести коррективы при доставке следующего приращения. Следующее приращение может состоять из нового кода, а также модификаций ранее предоставленного кода.
Преимущество в том, что формальности остаются в силе, но управление изменениями становится проще. Стоимость многократного тестирования и развертывания приложения будет выше, чем однократное.
Управление потоком программы
Выбор подхода к управлению потоком программы — очень архитектурная задача. Цель состоит в том, чтобы создать план вашего приложения, в котором, как только вы начнете добавлять функциональность и код, все станет на свои места. Если вы когда-либо просматривали или писали высококачественный код, вы понимаете этот принцип.
Код организатора
Первым шагом в проектировании потока программы является организация кода путем установления набора правил, помогающих создать схему или схему приложения. Обслуживание, отладка и исправление ошибок будут проще, поскольку код расположен в логическом месте. После того, как вы сделали основу, вы можете выбрать подход к реализации логики вашего приложения.
Шаблоны проектирования должны играть важную роль в разработке управления потоком программ. За прошедшие годы было написано много кода и разработано множество решений для повторяющихся проблем. Эти решения изложены в шаблонах проектирования. Применение шаблона проектирования к общей проблеме разработки программного обеспечения поможет вам создать решения, которые легко узнаваемы и могут быть реализованы вашими коллегами. Уникальные проблемы по-прежнему потребуют уникальных решений, но вы можете использовать шаблоны проектирования, которые помогут вам в их решении.
Создание проекта
слои
Первым шагом является рассмотрение логических слоев. Обратите внимание, что слои — это не то же самое, что слои, их часто путают или даже считают одним и тем же.
слои против слоев
Слои — это создание границ в вашем коде. Верхний уровень может иметь ссылки на код нижележащих уровней, но уровень никогда не может иметь ссылок на код вышележащего уровня. Уровни относятся к физическому распределению уровней между несколькими компьютерами. Например, в трехуровневом приложении пользовательский интерфейс предназначен для работы на настольном компьютере, логика приложения предназначена для работы на сервере приложений, а база данных работает на сервере базы данных. Слой может состоять из нескольких слоев.
Рисунок 8-1: Базовая трехуровневая организация
Слои относятся к уровням абстракции. Слои, показанные на рис. 8-1, справедливы для большинства приложений. Эти уровни также называются тремя основными слоями и могут иметь другие названия. Как правило, код на уровне представления может вызывать службы на уровне логики приложения, но уровень логики приложения не должен вызывать метод на уровне представления. Уровень представления никогда не должен напрямую вызывать уровень доступа к данным, так как это обойдет обязанности, реализуемые уровнем логики приложения. Уровень доступа к данным никогда не должен вызывать уровень логики приложения.
Слои — это просто абстракция, и, вероятно, самый простой способ реализовать слои — создать папки в вашем проекте и добавить код в соответствующую папку. Более полезным подходом было бы размещение каждого слоя в отдельном проекте, создавая таким образом отдельные сборки. Преимущество помещения логики вашего приложения в библиотечную сборку заключается в том, что это позволит вам создавать модульные тесты с помощью Microsoft Visual Studio или NUnit для проверки логики. Это также обеспечивает гибкость при выборе места для развертывания каждого уровня.
Физические уровни
В корпоративном приложении вы ожидаете наличия нескольких клиентов для одной и той же логики. Фактически, корпоративным приложением приложение делает то, что оно развертывается на трех уровнях: клиент, сервер приложений и сервер базы данных. Приложение Microsoft Office Access, созданное отделом продаж вашей компании, хотя и очень важно для отдела продаж, не является корпоративным приложением.
Обратите внимание, что логика приложения и уровни доступа к данным часто развертываются вместе на сервере приложений. Частью разработки проекта является выбор доступа к серверу приложений с помощью удаленных .NET или веб-служб. Что бы вы ни выбрали, вы добавите код для простого доступа к удаленным службам на уровне представления. Если вы используете веб-службы для доступа к службам на сервере приложений, Visual Studio .NET сделает всю работу за вас и сгенерирует код прокси, автоматически предоставив реализацию шаблона удаленного прокси.
Добавление узоров к слоям
Три основных уровня обеспечивают обзор высокого уровня. Давайте добавим несколько структурных шаблонов, чтобы создать надежную архитектуру предприятия. Результат показан на рис. 8-2.
Сосредоточьтесь на уровне логики приложения. На рис. 8-2 показано, что для доступа к логике приложения используется шаблон фасада. Фасад — это объект, предоставляющий упрощенный интерфейс для большей части кода, например библиотеки классов. Фасад может уменьшить зависимость внешнего кода от внутренней работы библиотеки, поскольку большая часть кода использует фасад, что обеспечивает большую гибкость при разработке системы. Для этого фасад предоставит крупнозернистый интерфейс для набора мелкозернистых объектов.
поток решений
Управление потоком программы, также известное как поток принятия решений, касается того, как вы проектируете сервисы на уровне логики вашего приложения или, как вы видели в предыдущем абзаце, как вы проектируете методы на своем фасаде.
Есть два подхода к организации ваших услуг:
- ориентированный на действие
- управляемый государством
Ориентированный на действия подход
Организуя сервисы на основе действий пользователя, вы реализуете логику приложения, предлагая сервисы, каждый из которых обрабатывает определенный запрос от уровня представления. Это также известно как шаблон сценария транзакции. Этот подход популярен, потому что он прост и выглядит очень естественно. Примерами методов, использующих этот подход, являются BookStoreService.AddNewOrder(Order order) и BookStoreService.CancelOrder(int orderId).
Логика, необходимая для выполнения действия, реализована в методе очень последовательно, что делает код очень читабельным, но также трудным для повторного использования. Использование дополнительных шаблонов проектирования, таких как шаблон табличного модуля, может повысить возможность повторного использования.
Государственный подход
Также можно реализовать поток решений приложения гораздо более ориентированным на состояние способом. Услуги, предлагаемые сервером приложений, носят более общий характер, например BookStoreService.SaveOrder(Заказ). Этот метод проверит статус заказа и решит, добавить ли новый заказ или отменить существующий заказ.
Проекты структуры данных
Вы должны сделать несколько вариантов при проектировании структур данных. Первый вариант — это механизм хранения данных, второй — предполагаемое использование данных, а третий — требования к версии. Есть три способа взглянуть на дизайн структуры данных:
- Услуги предлагают данные; data является отражением реляционной базы данных.
- Данные должны быть сопоставлены с объектами, а службы предоставляют доступ к объектам.
- Данные, предлагаемые службами, должны быть основаны на схеме.
Выбор одного из трех в качестве основы для вашей структуры потока данных должен быть сделан на ранней стадии процесса проектирования. Во многих компаниях есть руководство компании, которое предписывает один из трех вариантов для всех проектов, но, по возможности, вам следует переоценивать варианты для каждого проекта, выбирая оптимальный подход для текущего проекта.
Выбор механизма хранения данных
При разработке приложения вам, несомненно, придется разработать какое-то хранилище данных. Доступны следующие хранилища и формы хранения данных:
- Записывать
- файл app.config
- XML-файлы
- простые текстовые файлы
- База данных
- очередь сообщений
Каждый магазин имеет свои уникальные характеристики и может быть адаптирован к конкретным требованиям.
Проектирование потока данных
Поток данных с использованием ADO.NET
Внедрив сервисы, ориентированные на данные, на уровне логики приложения, вы спроектируете свой поток данных с помощью ADO.NET. Библиотека классов .NET Framework предоставляет обширный интерфейс прикладного программирования (API) для управления данными в управляемом коде. Этот API, называемый ADO.NET, можно найти в пространстве имен System.Data. Полное разделение носителей данных и хранилищ данных — важная конструктивная особенность ADO.NET. Такие классы, как DataSet, DataTable и DataRow, предназначены для хранения данных, но не сохраняют информацию о том, откуда эти данные. Они считаются независимыми от источника данных. Отдельный набор классов, например SqlConnection, SqlDataAdapter и SqlCommand, отвечает за подключение к источнику данных, получение данных и заполнение DataSet, DataTable и DataRow. Эти классы расположены в подпространствах имен, таких как System.Data.Sql, System.Data.OleDB, System.Data.Oracle и так далее. В зависимости от того, к какому источнику данных вы хотите подключиться, вы можете использовать классы в правильном пространстве имен, и в зависимости от объема используемого вами продукта вы обнаружите, что эти классы предлагают больше или меньше функциональных возможностей.
Поскольку DataSet не подключен к источнику данных, его вполне можно использовать для управления потоком данных в приложении. На рис. 8-5 показан поток данных при этом.
Давайте посмотрим на этот проект и представим, что кто-то зашел в ваш книжный магазин и заказал три книги. Уровень представления управлял состоянием корзины. Заказчик готов оформить заказ и предоставил все необходимые данные. Он выбирает отправить заказ. Веб-страница преобразует все данные в набор данных, содержащий две таблицы данных, одну для порядка и одну для порядка; вставляет DataRow для заказа; и вставляет три строки данных для строк заказа. Затем веб-страница снова отображает эти данные пользователю, привязывая элементы управления данными к набору данных и спрашивая «Вы уверены?». Пользователь подтверждает запрос, и он отправляется на логический уровень приложения. Уровень логики приложения проверяет набор данных, чтобы убедиться, что все обязательные поля имеют значения, и выполняет проверку, чтобы увидеть, есть ли у пользователя более 1000 US$. 00 по неоплаченным счетам. Если все идет хорошо, DataSet передается на уровень доступа к данным, который подключается к базе данных и генерирует операторы вставки из информации DataSet.
Использование DataSet таким образом — это быстрый и эффективный способ создания приложения и использования возможностей библиотеки классов Framework и возможности ASP.NET привязывать данные к различным элементам управления, таким как GridView, к DataSet. Вместо использования простых объектов DataSet вы можете использовать объекты Typed DataSet и улучшить процесс написания кода, реализовав код на уровне представления, а также на уровне логики приложения. Преимущество этого подхода также является его недостатком. Небольшие изменения в модели данных не обязательно приводят к тому, что многим методам приходится менять свои сигнатуры. Так что с точки зрения обслуживания это работает очень хорошо. Если вы помните, что уровень представления — это не обязательно пользовательский интерфейс, это также может быть веб-служба. И если вы изменяете определение DataSet, возможно, потому, что вы переименовываете поле в базе данных, вы изменяете контракт, на который подписывается веб-служба. Как вы понимаете, это может привести к серьезным проблемам. Этот сценарий хорошо работает, если уровень представления представляет собой просто пользовательский интерфейс, но для интерфейсов к внешним системам или компонентам вы захотите скрыть внутреннюю работу вашего приложения и преобразовать данные во что-то другое, чем прямой клон вашей модели данных и вы захотите создать объекты передачи данных (DTO).
Поток данных с использованием объектно-реляционного сопоставления
Поток данных с использованием ADO.NET — это очень ориентированный на данные подход к управлению потоком данных. Данные и логика дискретны. На другом конце спектра используется более объектно-ориентированный подход. Здесь классы создаются для группировки данных и поведения. Цель состоит в том, чтобы определить классы, имитирующие данные и поведение бизнес-домена, для которого было создано приложение. Результат часто называют бизнес-объектом. Набор бизнес-объектов, составляющих приложение, называется моделью предметной области. Некоторые разработчики утверждают, что богатая модель предметной области лучше подходит для разработки более сложной логики. Трудно доказать или опровергнуть такое утверждение. Просто знайте, что у вас есть выбор, и вы должны его сделать.
На рис. 8-6 показан поток данных, аналогичный рисунку 8-5, за исключением того, что теперь вы добавили слой реляционного отображения объектов и заменили объекты DataSet другими носителями данных.
Теперь сделайте то же самое шаг за шагом, что и раньше; представьте, что кто-то подключился к вашему книжному магазину и заказал три книги. Уровень представления управлял состоянием корзины. Заказчик готов оформить заказ и предоставил все необходимые данные. Он выбирает отправить заказ. Веб-страница превращает все данные в DTO, храня данные для одного заказа и с тремя строками заказа, создавая объекты по мере необходимости. Веб-страница снова отображает эти данные пользователю, привязка данных контролирует DTO с помощью ObjectDataSource в ASP.NET 2.0 и спрашивает: «Вы уверены?». Пользователь подтверждает выбор, и DTO отправляется на логический уровень приложения. Уровень логики приложения преобразует DTO в бизнес-объект типа Order со свойством содержать три объекта OrderLine. Метод Заказ. Validate() вызывается для проверки заказа и проверки того, что все обязательные поля имеют значение, а также выполняется проверка, чтобы определить, есть ли у пользователя более R$ 1000,00 в ожидающих квитанциях. Для этого ордер вызовет Order.Customer.GetOutstandingBills(). Если все хорошо, вызывается метод Order.Save(). Запрос будет проходить через уровень объектно-реляционного сопоставления, где запрос и строки запроса сопоставляются с DataTable в наборе данных, а набор данных передается на уровень доступа к данным, который подключается к базе данных и генерирует операторы вставки из информацию в наборе данных. Конечно, существует множество способов объектно-реляционного сопоставления, но не все из них будут включать преобразование в набор данных. Некоторые создают оператор вставки напрямую, но по-прежнему используют уровень доступа к данным для выполнения этого оператора.
Как видите, некоторые преобразования происходят. Использование DTO необходимо, поскольку бизнес-объект реализует поведение, а поведение может быть изменено. Чтобы свести к минимуму влияние этих изменений на уровень представления, вам необходимо преобразовать данные из бизнес-объекта в объект передачи данных. В Java объект передачи данных часто называют объектом значения.
Большим преимуществом работы с бизнес-объектами является то, что это действительно помогает организовать ваш код. Если вы оглянетесь на сложную логику, то увидите, что она обычно очень удобочитаема, потому что в ней очень мало кода. Недостатком является то, что большинство хранилищ данных по-прежнему являются реляционными, и сопоставление бизнес-объектов с реляционными данными может стать довольно сложным.
сервисы на основе схемы
Вы только что видели две противоположности, когда дело доходит до управления потоком данных. Возможны многие вариации. Распространенным является вариант, в котором набор данных используется в качестве основного носителя данных пользовательского интерфейса для хранения данных, но для веб-сервисов, вызываемых из других систем, используются отдельные схемы (DTO). Прикладной уровень преобразует реляционные данные в предопределенную схему. Основное преимущество этого заключается в том, что любое приложение, которое ссылается на службу, не зависит от какой-либо внутренней реализации компонента. Это обеспечивает большую гибкость в управлении версиями, обратную совместимость интерфейсов и возможность изменять реализацию компонента без изменения интерфейса службы.
Конечно, вы можете использовать бизнес-объекты в веб-приложении и обойти преобразование DTO, но обычно это хорошо работает только в том случае, если логика приложения реализована вместе с веб-приложением. Помните, что для вызова Order.Save() вам потребуется подключение к базе данных. Желательно ли это, зависит от вас и, возможно, от вашего директора по безопасности.