Статья:Правильный подход к проектированию ПО

[[NiGHT]DarkAngel]

Правильный подход к проектированию ПО(часть 1)

Введение

При разработке программного обеспечения мы не задумываемся о дальнейшей его судьбе. А что если:
• Придется масштабировать приложение
• Переносить его с Web-приложения на Windows Forms
Придется его полностью переписывать, заново строить архитектуру приложения, все это лишние трудозатраты. А ведь можно было просто изначально подумать над этим?
Вот отсюда и приходит тема этой статьи.

Начинаем проектировать

Для примера возьмем самую простую функцию в программе «Регистрация пользователей»

Она будет разбита на 4 проекта: Domain, Infrastructure,View и ViewModel

Поговорим о каждом из них в отдельности:
• Domain – В этом проекте хранится вся бизнес логика программы (Entity and Services)
• Infrastructure – В этом проекте хранятся все классы интерфейсов
• View – В этом проекте хранится тот вид отображения проекта который вы захотите (Windows Forms или Web Application)
• ViewModel – В этом проекте хранятся наши вспомогательные классы для связи Domain и View

Стоит оговорить следующие зависимости(Reference):
• Domain видит Infrastructure
• ViewModel видит Domain
• View видит ViewModel, Infrastructure

В Domain существуют две папки Entity и Service

Теперь можно писать приложения все сущности складываются в Entity, все необходимые операции с ними в Service.

Во ViewModel складываются классы-прослойки, которые получают на вход данные, передают их на обработку сервисам, сервисы возвращают какой-то результат во ViewModel, а она возвращает View что сервис отработан успешно или нет и View выводит только результатирующие сообщение.

Вывод

Таким подходом мы смогли обеспечить легкую масштабируемость приложения, легкое внедрение новых сервисов для вашего приложения и безболезненный переход от Web Application на Windows Forms и обратно.

От автора

Это моя первая статья, если эта тема интересна, могу продолжить развития цикла статей, с подключением репозиториев при разработке,O/R NHibernate, и примерами подкрепленными кодом.
Пример ориентирован на C# и ASP.NET

P.S. Рад буду слышать любую критику и пожелания. Посмотрел вроде такой статьи нет.

[Forcer]

Слишком мало. Основная идея - четко разделять уровни приложения.

Переносить его с Web-приложения на Windows Forms
Может реально потребоваться такое? Есть примеры?

Она будет разбита на 4 проекта
именно проекты? просто уровни могут быть разделены четко и в одном проекте. Если все делать в разных проектах, то нужно тогда настраивать references между проектами, что, мне кажется, вызывает просто ненужные сложности.
Для примера возьмем самую простую функцию в программе «Регистрация пользователей»
Больше в статье не увидел ни одного обращения к этой "программе".

Стоит оговорить следующие зависимости(Reference):
Лучше показывать на диаграммах. http://yuml.me/

Я считаю, тебе самому нужно почитать больше литературы на тему проектирования. А вообще, тема интересная.

[[NiGHT]DarkAngel]

Может реально потребоваться такое? Есть примеры?
WebMoney использование Windows приложения и Web-интерфейса


именно проекты? просто уровни могут быть разделены четко и в одном проекте. Если все делать в разных проектах, то нужно тогда настраивать references между проектами, что, мне кажется, вызывает просто ненужные сложности.

В одном проекте это не все так наглядно.
В чем сложность заключается? Добавить его в список?


Больше в статье не увидел ни одного обращения к этой "программе".

Сначало хотел пример привести с созданием такого приложения


Лучше показывать на диаграммах. http://yuml.me/

Спасибо,статья написана просто для примера,вдруг это никого не заинтересует ... исправлюсь в след. раз.



Я считаю, тебе самому нужно почитать больше литературы на тему проектирования.

Учиться никогда не поздно,принимаю как хорошую критику. Только в данном моменте, хотелось бы уточнить из-за чего такой вывод был сделал?



А вообще, тема интересная.


С этим согласен 100%

[Algol]

DarkAngel']Спасибо,статья написана просто для примера,вдруг это никого не заинтересует ... исправлюсь в след. раз.

Ну и зачем писать такие статьи "для примера" ?
Тем кто в этом разбирается - статья просто смешная. Для тех же кто не разбирается - слишком короткая и наивная ("Таким подходом мы смогли обеспечить легкую масштабируемость приложения").

Либо пиши действительно серьезные статьи (расмотрев например реализации MVC/MVP) либо пиши действительно примеры, с реальным кодом, модульностью, коментариями и т.д.

[[NiGHT]DarkAngel]

Ну и зачем писать такие статьи "для примера" ?
Тем кто в этом разбирается - статья просто смешная. Для тех же кто не разбирается - слишком короткая и наивная ("Таким подходом мы смогли обеспечить легкую масштабируемость приложения").

Либо пиши действительно серьезные статьи (расмотрев например реализации MVC/MVP) либо пиши действительно примеры, с реальным кодом, модульностью, коментариями и т.д.
Спасибо за критику, исправлюсь и дополню ее примером и диаграммами классов, Use Case диаграмм

[Qwazar]

Блин, это не статья. Если ты пытался изобразить MVC, то вот посмотри примерно как выглядят статьи на эту тему:

http://www.rsdn.ru/article/patterns/ModelViewPresenter.xml
http://www.rsdn.ru/article/patterns/generic-mvc.xml
http://www.rsdn.ru/article/patterns/generic-mvc2.xml

[ss88]

Очень интересная статья... Может кратость и сестра таланта, но не в этом случае.

Я не по-наслышке связан с архитектурой корпоративных информационных систем (КИС) и могу сказать лишь то, что такие статьи (что-то даже по объему на статью не тянет) лучше "убивать при рождении" или доводить до ХОТЬ КАКОГО-НИБУДЬ вида.

Поговорим о каждом из них в отдельности:
• Domain – В этом проекте хранится вся бизнес логика программы (Entity and Services)
• Infrastructure – В этом проекте хранятся все классы интерфейсов
• View – В этом проекте хранится тот вид отображения проекта который вы захотите (Windows Forms или Web Application)
• ViewModel – В этом проекте хранятся наши вспомогательные классы для связи Domain и View
1. В модель предметной области обычно входят ТОЛЬКО описания классов ПОНЯТИЙ и практически никакой бизнес-логики (например, в серьезных КИС в одних понятиях черт ногу сломит, что приводит к делению оных на отдельные пакеты и подпакеты).
2. Что-то типа мостового пакета Infrastructure.... Что за слово? Откуда оно? Кто здесь? Вы претендуете на роль законодателя мод? Спешу вас разочаровать, вы, по всей видимости, не Гамма, не Влиссидес, не Фаулер, не Бек и, в общем случае, не столп мирового масштаба в ОО-проектировании.

Domain видит Infrastructure
Отэта да... Карандаш знает все о всех бумажках в мире, на которых он может что-то написать....

В общем, можно продолжить и обхаять все до последней буквы в текущем варианте "статьи", но это утомительно. Можно сказать лишь то, что если вы придумали что-то, действительно стоящее, то опишите это как следует - с аргументацией, мотивацией, примерами, областью применения, известными применениями. Хорошим примером подобного оформления является классический фундаментальный труд Э. Гамма и Ко. "Приемы объектно-ориентированного проектирования...". Итого, ИМХО, пока УЖАСНО. Будем ждать продолжения.

[Gar|k]

В институтах преподают целый предмет называемый "технология программирования". ИМХО прочтение курса лекций по нему гораздо полезнее чем прочтение этой статьи :)