Недавно купил книгу Стива Макконнелла. За 5 дней прочел половину... Ошибки разработки о которых пишет автор  - практически все присутствуют в моей работе. 
Хочу научиться грамотно разрабатывать ПО. Сейчас мне потребовалось разработать программку, которая тянет данные из БД, выполняет над ними необходимые расчеты (если это того требуется) и передавала их в генератор отчетов, который, в свою очередь экспортировал их в форматы екселя, пдф, ворда или др. На скорую руку сделал программу - работает, но теперь хочу написать ее грамотно, как полагается: разработать схему приложения, продумать архитектуру, реализовать расслоение приложения, организовав отдельными блоками GUI, АDO-блок, и блок, содержащий основную логику приложения (я выделил для себя эти три уровня). Затем продумать Классы, их состав, как они будут взаимодействовать друг с другом... Написать псевдокод и, наконец-то перейти непосредственно к процессу программирования. Затем - отладка. 
Разработка ПО - итеративный процесс, но итеративным он должен быть на стадиях, предшествующих написанию кода. Вполне возможно, что схема, придуманная мною, представляет не лучший вариант решения задачи. Лучше узнать об этом и исправить ситуацию сейчас, чем узнать и исправлять кучу кода. Я хотел бы выложить свою, имеющуюся на данный момент схему и т.п. (подробно оформлено и выложено в виде pdf-документа). Возможно кто-то ознакомившись с моим планированием и организацией программы выдаст какие-то замечания и советы. Сейчас меня интересуют замечания со стороны по поводу того, как я организовываю структуру своего приложения. Архитекрура приложения спланирована мною до конца (как мне кажется). Прежде чем продолжу разработку далее, мне бы хотелось услышать замечания со стороны специалистов. Выкладываю на предмет замечаний файл в формате пдф (конвертировал из ворда): 
исправленная и доработанная версия файла

Это сообщение отредактировал(а) Compositum - 20.6.2008, 13:02

Доработал файл до конца с внесением в него существенных изменений.


Это сообщение отредактировал(а) Compositum - 20.6.2008, 12:57

Посоветовали вместо статических классов использовать синглтоны - тогда будет возможность использовать интерфейсы. 
нашел в википедии:

Сейчас сижу разбираюсь с синглтонами... ведь объект не обязательно создавать как public или internal, могу сделать его private.

Так же посоветовали переименовать пространство ControlPanel  в Core (сбивает с толку, наводя ассоциацию на GUI). 
Пожалуй переименую. 
Соответственно и класс ProgramControls переименую в ProgramCore. 
Насчет синглтонов пока думаю. 

Это сообщение отредактировал(а) Compositum - 20.6.2008, 14:31

Размышляя на тему архитектуры пришел к выводу, что спланированный мною вариант ни к черту не годится - блоки программного кода должны взаимодействовать друг с другом посредством интерфейсов. Чтобы реализовать интерфейс - нужно использовать объекты не статического класса. В виду этого сама собой напрашивается абсолютно другая архитектура приложения, в которой одни блоки кода будут представлять собой объекты, инкапсулированные в свойства другого блока. Такая архитектура представляется мне более правильной. 
Кроме того отделение GUI я произвел не корректно (т.е. не до конца), т.к. в данном случае я не смогу заменить GUI Winforms на GUI WPF - поскольку методы, которые я использую для работы с GUI в параметрах запрашивают указание контрола именно WinForms. 
Если бы можно было реализовать привязку контролов к данным через BuindingSource - было бы здорово, но вот беда - ни Тривью, ни листвью не содержат свойства БиндингСоурса....
Может быть объекты WPF реализуют те же интерфейсы, что и соответствующие им объекты из винформз? пока не знаю - не смотрел...
Если таких интерфейсов нет - буду перегружать методы. Пока что знаю 2 вида GUI - Winforms  и WPF. Т.о. каждый метод, который будет работать с компонентом GUI будет перегружен в двух вариантах. Сейчас иного способа не вижу...
_____________________________________________________________________________
решение где-то рядом... и я его найду....

Это сообщение отредактировал(а) Compositum - 20.6.2008, 16:53

Проверил наличие общих интерфейсов на примере контрола TreeView:

Результат - общих интерфейсов нет. Значит верное решение - перегрузка методов.

Хотя можно поступить иначе.... Исходя из понимания того, что в процессе развития .NET-технологий набор контролов GUI будут изменяться - нет смысла подстраиваться под каждый контрол - за всем не угонишься. Вывод можно - не оперировать контролами GUI из "ядра" программы, а позволить этим контролам самим заполнять себя данными - пусть методы "ядра" возвращают массив нужных записей или объектов. Т.о. в событиях контрола нужно будет добавить несколько строчек кода, формирующих заливку в себя полученных данных - скорее всего это будет код цикла. 
Но будет ли это являться отделением интерфейса, ведь в него я добавляю не просто вызов метода "ядра", который всю остальную работу сделает сам, а размещаю небольшой фрагмент кода, который заполнит данными этот контрол..... Не знаю...  
Но опять же.... с очередной стороны: а что, количество вариантов контролов будет так высоко, что я буду просто часами решать, какой из них подойдет для размещения в нем такого-то вида данных? Нет конечно же... А значит? Значит, что все же лучше перегружать методы, учитывая в каждой перегрузке те контролы, которым могу назначить данные. Т.о. В событии контрола будет лишь одна строка кода- вызов метода "ядра". Могу ли я утверждать, что в этом случае получаю чистое отделение GUI от кода? Со спокойной совестью могу утверждать - да, несомненно... А в виду того, что данный топик я блюду более для себя, чем для др. (все равно тема кроме меня никого не волнует) - я продолжу работу в следующем направлении:

Перепишу полностью архитектуру приложения:
- ИМХО - блоки кода, должны взаимодействовать друг с другом посредством четко обозначенных контрактов, а значит статические классы не пойдут для этого дела. Классы должны быть sealed, кроме того необходимо реализовать механизм, чтобы в текущем домене экземпляры этих классов не могли создаваться в количестве более одного (не вижу смысла в создании более одного такого класса, а следовательно нужно предотвратить возможность создания такового со стороны "доброжелателей").
Кроме того, в приложении нужно продумать механизм, позволяющий добавлять в этот "конструктор" очередные порции "кубиков" - например, если я захочу реализовать систему доступа к программе, или произвести ее локализацию.... Подключил модуль - он стал частью механизма и все должно слаженно работать.... Задумка красивая... И то, что тренироваться реализовать это я буду на маленьком приложеньице нисколько не умаляет самого главного замысла - научиться проектировать приложение грамотно, используя по максимуму все имеющиеся возможности ООП. Надеюсь, что у меня получится... К сожалению, на данный момент у меня что ни час, то новый вариант решения той или иной проблемы, то вдруг все отметается и я возвращаюсь к старой версии... Хотелось бы, чтобы в конце концов вся шелуха отсеилась....