Правильный подход к проектированию ПО(часть 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. Рад буду слышать любую критику и пожелания. Посмотрел вроде такой статьи нет.
Слишком мало. Основная идея - четко разделять уровни приложения. Может реально потребоваться такое? Есть примеры? именно проекты? просто уровни могут быть разделены четко и в одном проекте. Если все делать в разных проектах, то нужно тогда настраивать references между проектами, что, мне кажется, вызывает просто ненужные сложности. Больше в статье не увидел ни одного обращения к этой "программе". Лучше показывать на диаграммах. http://yuml.me/ Я считаю, тебе самому нужно почитать больше литературы на тему проектирования. А вообще, тема интересная.
WebMoney использование Windows приложения и Web-интерфейса В одном проекте это не все так наглядно. В чем сложность заключается? Добавить его в список? Сначало хотел пример привести с созданием такого приложения Спасибо,статья написана просто для примера,вдруг это никого не заинтересует ... исправлюсь в след. раз. Учиться никогда не поздно,принимаю как хорошую критику. Только в данном моменте, хотелось бы уточнить из-за чего такой вывод был сделал? С этим согласен 100%
Ну и зачем писать такие статьи "для примера" ? Тем кто в этом разбирается - статья просто смешная. Для тех же кто не разбирается - слишком короткая и наивная ("Таким подходом мы смогли обеспечить легкую масштабируемость приложения"). Либо пиши действительно серьезные статьи (расмотрев например реализации MVC/MVP) либо пиши действительно примеры, с реальным кодом, модульностью, коментариями и т.д.
Блин, это не статья. Если ты пытался изобразить 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
Очень интересная статья... Может кратость и сестра таланта, но не в этом случае. Я не по-наслышке связан с архитектурой корпоративных информационных систем (КИС) и могу сказать лишь то, что такие статьи (что-то даже по объему на статью не тянет) лучше "убивать при рождении" или доводить до ХОТЬ КАКОГО-НИБУДЬ вида. 1. В модель предметной области обычно входят ТОЛЬКО описания классов ПОНЯТИЙ и практически никакой бизнес-логики (например, в серьезных КИС в одних понятиях черт ногу сломит, что приводит к делению оных на отдельные пакеты и подпакеты). 2. Что-то типа мостового пакета Infrastructure.... Что за слово? Откуда оно? Кто здесь? Вы претендуете на роль законодателя мод? Спешу вас разочаровать, вы, по всей видимости, не Гамма, не Влиссидес, не Фаулер, не Бек и, в общем случае, не столп мирового масштаба в ОО-проектировании. Отэта да... Карандаш знает все о всех бумажках в мире, на которых он может что-то написать.... В общем, можно продолжить и обхаять все до последней буквы в текущем варианте "статьи", но это утомительно. Можно сказать лишь то, что если вы придумали что-то, действительно стоящее, то опишите это как следует - с аргументацией, мотивацией, примерами, областью применения, известными применениями. Хорошим примером подобного оформления является классический фундаментальный труд Э. Гамма и Ко. "Приемы объектно-ориентированного проектирования...". Итого, ИМХО, пока УЖАСНО. Будем ждать продолжения.
В институтах преподают целый предмет называемый "технология программирования". ИМХО прочтение курса лекций по нему гораздо полезнее чем прочтение этой статьи
