Comments 28
Пересмотреть архитектуру приложения и хотя бы выделить общий класс для работы с данными.
Я раньше так и делал, как учили в университете, когда писал под vs2003. А сейчас — DataGridView + типизированные датасеты. Это быстро и удобно. Или так делать неправильно?
Быстро и удобно сейчас — да, а потом получите «неповоротливую» архитектуру, в которую внести изменение будет тяжелее, чем написать приложение заново.
Т. е. предлагаемый Майкрософт стиль разработки изначально ущербен?
Посоветуйте, пожалуйста, хорошую альтернативу. Желательно, чтобы не вспоминать классы типа SqlConnection и методы Open() и Close().
Посоветуйте, пожалуйста, хорошую альтернативу. Желательно, чтобы не вспоминать классы типа SqlConnection и методы Open() и Close().
Причем тут технологии Microsoft'а доступа к данным и то, как вы их используете? Я вам говорю о том, что нужно отделить бизнес логику, логику уровня БД и логику отображения. У вас сейчас получается что на форме и бизнес-логика, и доступ к данным и их отображение.
Если вы уж хотите работать именно так, то используйте 2 вариант. Все равно и тот и другой неверный подходы.
Если вы уж хотите работать именно так, то используйте 2 вариант. Все равно и тот и другой неверный подходы.
Ещё раз повторю, что этой красивой трёхуровневой модели нас учили ещё в университете. Бизнес-логика, кстати, реализуется фактически вообще в хранимых процедурах БД, а никак не в формах. А интерфейс пользователя и интерфейс БД, действительно, сливаются. Потому что к этому нас толкает VS2005. Ляпнул на форму DataGridView. Приделал к тему типизированный датасет. В красивом графическом редакторе расставил в датасете таблички. В коде вызвал метод Fill() когда надо, и всё готово.
А как Вы предлагаете конструировать приложения?
А как Вы предлагаете конструировать приложения?
Вы сначала решите что вы конструируете: поделку на один раз, которую потом переделывать не будете или «приложение». В первом случае вас мало волнует проблемы поддержки этого «приложения» в будущем, в последнем — вы думаете в первую очередь о будущем и готовы потерять какое-то время на первоначальной разработке.
DataGridView — это GoTo XXI века. Когда вы вместо разделения программы на части вставляете нифига не описанные связи между его частями. И как и много лет назад его примение позволяет быстрее получить «что-то работающее», но усложняет получение вменяемой архитектуры потом. Впрочем часто вменяемая архитектура и не нужна — но причём тут тогда угрызения совести по типу «нелогично с точки зрения ООП»? Снявши голову по волосам не плачут…
DataGridView — это GoTo XXI века. Когда вы вместо разделения программы на части вставляете нифига не описанные связи между его частями. И как и много лет назад его примение позволяет быстрее получить «что-то работающее», но усложняет получение вменяемой архитектуры потом. Впрочем часто вменяемая архитектура и не нужна — но причём тут тогда угрызения совести по типу «нелогично с точки зрения ООП»? Снявши голову по волосам не плачут…
Это называется «спагетти код».
я отчего то сомневаюсь что ваше windows-приложение замедлится из за одного запроса
какое прогнозируемое кол-во рабочих мест в системе?
использовать LEFT/INNER JOIN в запросе?
В смысле, добавить целую колонку к загружаемой таблице, в которой будет написано одно и то же «Красная зорька», «Красная зорька», «Красная зорька»? По-моему, тоже не самый идеологически верный способ.
хм. чет я тогда не понимаю вашу архитектуру. есть таблица заказчиков, есть таблица договоров. у договоров есть поле customer_id с id заказчика. по идее это one-to-many ассоциация. и выдирать надо все договоры с заказчиком id=12345
вобщем, подумайте на архитектурой.
вобщем, подумайте на архитектурой.
Всё правильно, выдираем все договоры с заказчиком id=12345, и надо в шапке отобразить, что этого заказчика id=12345 зовут Филькин Иван Петрович.
Есть такой период в жизни каждого программиста, когда резко обостряется внутренняя борьба за «идеологическую правильность». Лично я всегда называю этот процесс «битвой добра со здравым смыслом». Обычно в этой «битве» разработчика преследует желание сделать всё везде идеально и универсально (сторона добра =)).
… пропуская занудствования по поводу того, почему это не лучший вариант и почему нужен баланс…
В вашем случае можно делать любым удобным и нравящимся способом, обратив внимание при этом на консистентность (похожие проблемы в других частях архитектуры лучше решать одинаково) и лёгкость изменения такого поведения в будущем. Попытка выбирать нужные данные заранее может подсказать вам о необходимости создания нового бизнес-объекта, но опять же, не нужно сразу кидаться его делать, вероятно его появление пока не оправдано.
А еще… «We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.» (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)
… пропуская занудствования по поводу того, почему это не лучший вариант и почему нужен баланс…
В вашем случае можно делать любым удобным и нравящимся способом, обратив внимание при этом на консистентность (похожие проблемы в других частях архитектуры лучше решать одинаково) и лёгкость изменения такого поведения в будущем. Попытка выбирать нужные данные заранее может подсказать вам о необходимости создания нового бизнес-объекта, но опять же, не нужно сразу кидаться его делать, вероятно его появление пока не оправдано.
А еще… «We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.» (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)
Спасибо за первый ценный комментарий! :) Отплюсовал бы от всей души, но я хабралох, поэтому пишу просто так! Действительно, очень мудро.
Фразу Кнута все очень любят выдирать из контекста. Речь у Кнута идёт о том, что всякие микрооптимизации (типа вынесения a+1 из цикла руками) скорее идут во вред, чем на пользу. Сейчас от 97% из тех 97%, о которых говорил Кнут уже даже и не вспоминают — всё отдано на откуп компилятору. И с лёгкостью прикручивают этот принцип и к отсавшимся 6%. А потом всё начинает дико жрать память и тормозить…
Кнут и другие прежде всего писали о вредности преждевременной оптимизации, о вредности проектирования «от эффективности». Ключевое слово — преждевременная. А уж обнаружение узких мест — это дело техники. Разумеется никто не говорит о том, что проектировать нужно без всяких мыслей об эффективности кода, тут, как и много где, нужен разумный баланс.
Можно передавать в родительскую форму не просто ID плательщика, но строку из DataSet'а для этого плательщика (читай: набор данных о нем, и в приложении может быть представлена на как строка DataSet'а, а как объект класса «Плательщик»), форма уже что ей надо — возьмет.
И с точки зрения ООП итоже довольно логично: форме передается плательщик (не просто его ИД), а она показывает договоры, с ним связанные
И с точки зрения ООП итоже довольно логично: форме передается плательщик (не просто его ИД), а она показывает договоры, с ним связанные
Я бы сделал вот как: передаем id, при этом заносим запись в кэш. В следующий раз сможем вытащить из кэша. Как вариант расширения — если данных не очень много — загружать все что надо при запуске приложения сразу в кэш. Однако встает вопрос с определением валидности кэша, но это тема другого разговора.
Sign up to leave a comment.
Дилемма программиста