Последние комментарии

Максим

Паттерн MVVM в чистом виде хорош только для относительно простых проектов. Для создания крупных проектов с дружественным для пользователя интерфейсом он не всегда удобен. Например, в рамках данного паттерна, довольно сложно в нужные моменты автоматически выставлять фокус в поле ввода, в WP7 ApplicationBar не поддерживает DataBinding и приходится писать свою обертку и так далее.  

VVS

Для WPF можно использовать паттерн mvvm(model view viewmodel), он просто великолепно справляется с задачей разделения ответственности в коде. При этом во всех модулях форм не будет ни одной строчки вашего кода (только автоматически сгенерированный).
Зачем все это нужно?
Ваш код станет четко структурированным, его будет легко сопровождать, очень легко тестировать, и т.д. Попробуйте потестируйте ваш код "в модулях формы", ничего хорошего у вас не выйдет.

Максим

Согласен с ораторами, что это разные гаджеты и проигрыватель в телефоне не способен собой заменить плеер, разве только как временное решение.
На счет фэйсбука (хотя я там даже не зарегестрирован) - будет полезен андроид

Михаил

Как вскрыть пароль, скачал програму как ей пользоваться?

Михаил Фленов

Посмотри для примера DPhotoWorkshop. Не идеал проектирования (я проект набросал за неделю), но хотя бы какое-то представление даст.

ronin

я понимаю о чём вы, но лично я с таким не сталкивался, я не представляю как можно спихать всё в один модуль, ведь всё равно, если брать тот же delphi, для каждой формы создаётся отдельный модуль и логика работы именно с этой формой, а не со всеми остальными формами, находится в модуле этой формы, так же как и модули для работы с данными преполагают размещение действий по работе с бд

ronin

спасибо посмотрел, хм... в большинстве я согласен, но в принципе у меня изначально так проектируется приложение, модули формы для интерфейса, модули данных для работы с базой данных, а писать свою прослойку в виде классов для работы например с базой данных дорогое удовольствие, по крайней мере для меня, я не вижу ничего плохого в моём подходе, и при смене например системы доступа к данным мне достаточно будет переработать модули данных

опять же я слабо представляю как можно отделить интерфейс программы от движка, было бы неплохо на примере, ведь в модуле формы я всего лишь описываю логику интерфейса (обработчики событий...), а всё остальное как раз и носит модульную структуру и соответствует принципам ООП (модули данных, библиотеки компонентов), разве не так? по моему delphi (и другие среды) именно так и проектировались, так что хоть убей не понимаю что не так в этом подходе

ну а по поводу конкретного примера, про веб интерфейс, конкретно в моём случае система применяется для конкретной задачи (оперативный учёт на производстве), в которой не предвидится и навряд ли когда либо такое понадобится, есть спектр решаемых задач, и система успешно с этим справляется

если бы стояла такая задача, или предполагалась необходимость доступа через веб, то конечно я бы думал над этой задачей, и систему проектировал бы изначально по такому принципу как вы предлагаете

Legens

мир в котором программисты пишут (нормальный проект я не говорю про project с 10 строчками работы с формой) всё в одном общем модуле не разделяя проект ЭТО КАША!!!!!)) в которой им же потом и копаться, я молчу про групповую разработку.......  

Михаил Фленов

Книг не планирую писать

Михаил Фленов

2ronin

Дописал пару абзацев еще с примерами в статью