Проектирование бизнес-логики работы с БД

← →
zorik © (2008-12-19 17:38) [0]

В последнее время стал чаще задумыватся над тем, а правильно ли я делаю? Разрабатывая очередное приложение или расширяя функциональность старого, встает проблема: а как сделать так, чтоб потом вносить изменения, расширять функциональность, переделывать некоторые методы было легко и прозрачно. Как "вытягивать" данные? Напрямую через компоненты доступа, или сначала загружать в компоненты приложения. И еще настройки, логирование, взаимодействие визуальных компонентов с объектами... Порождать ли один "мега-класс" - родитель для всего приложения?... Нужна очень абстрактная модель.

Гуглю тут понемножку. Может у кого есть линки с менее абстрактными понятиями - поделитесь )

Вот такие философские мысли в пятницу вечером...

← →
Ins © (2008-12-19 17:41) [1]

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

Как правило, чем из более абстрактных сущностей выстроена система, тем проще ее потом менять и развивать. Чем больше в коде неизолированной конкретики, тем соответственно, сложнее.

← →
zorik © (2008-12-19 17:50) [2]

> Ins © (19.12.08 17:41) [1]

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

← →
zorik © (2008-12-19 17:51) [3]

> Ins © (19.12.08 17:41) [1]

Полностью согласен

← →
Павел Калугин © (2008-12-19 17:56) [4]

> [0] zorik © (19.12.08 17:38)

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

← →
Ins © (2008-12-19 18:02) [5]

> Может у кого есть линки с менее абстрактными понятиями -
> поделитесь )

Где-то на RSDN видел статью с примерами применения паттернов в Delphi, сейчас что-то найти сходу не смог... Попробуйте Вы. А по мне, так главное понять общую идею, от общего к частному двигаться тут, как мне кажется, правильнее.

Кстати, советую еще Фаулера почитать, если не сделали этого раньше. Не всегда (читай - почти никогда) удается с первого раза спроектировать на все случаи жизни. А по сему нужно владеть приемами рефакторинга.

← →
zorik © (2008-12-19 21:33) [6]

> Где-то на RSDN видел статью с примерами применения паттернов
> в Delphi

Вот она: http://www.rsdn.ru/article/patterns/patterns.xml

← →
jack128_ (2008-12-19 21:51) [7]

> Как правило, чем из более абстрактных сущностей выстроена
> система, тем проще ее потом менять и развивать. Чем больше
> в коде неизолированной конкретики, тем соответственно, сложнее.
>

любую проблему проектирования можно решить введением дополнительного абстрактного слоя, кроме проблемы слишком большого количества абстрактных слоёв(с) кто-то с RSDN
;-)

← →
DVM © (2008-12-19 22:04) [8]

> Ins ©

> Где-то на RSDN видел статью с примерами применения паттернов
> в Delphi

Есть мнение, что паттернов проектирования надо касаться в тот момент, когда уже сам их начинаешь применять в работе, даже не задумываясь о том, что применяешь какие-то паттерны. Вот тогда можно заняться их изучением и систематизацией собственного опыта. Изучение паттернов, когда человек еще сам до них не дорос только вредит. Это только лишь одно из мнений и я с ним согласен.

← →
Ins © (2008-12-20 00:02) [9]

> Это только лишь одно из мнений и я с ним согласен.

Я тоже :)

← →
Германн © (2008-12-20 01:31) [10]

> jack128_ (19.12.08 21:51) [7]

+1

← →
Германн © (2008-12-20 01:42) [11]

> zorik © (19.12.08 17:38)

А в целом это очень хорошо может объяснить ЮЗ. (Может он даже уже и объяснял это на форуме, а может и не раз, но очень давно. Я по-крайней мере не помню).
Для разработки хорошей, нормально работающей системы, которая должна иметь возможность развиваться и улучшаться без особого напряга, весьма недостаточно наличия только "руководителя проекта" и "программиста".

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

← →
zorik © (2008-12-20 17:38) [12]

> Германн © (20.12.08 01:42) [11]

А если программист и руководитель в одном лице, то это вообще капут (((

> А в целом это очень хорошо может объяснить ЮЗ

Надо поискать

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

← →
zorik © (2008-12-20 17:38) [13]

> А уж если речь идёт о ИП (ЧП)

Это что?

← →
Поросенок Винни-Пух © (2008-12-20 17:49) [14]

Оно все как-то несвязанно

И это правильно. Когда все взаимосвязанно тогда все намного хуже.

← →
MsGuns © (2008-12-20 19:42) [15]

Чтбы приступать к проектироанию любой сколь-нибудь "интеллектуальной" самонастаивающейся (самоподстаивающейся) системы, надо иметь как правило 3 вещи:

1. Доскональное знание предмета автоматизации
2. Достаточно мощный и гибкий инструментарий
3. Весьиа значичельные ресурсы времени и финансирования.

Та же 1С в своем нынешнем универсальном виде появилась далеко не сразу и в результате очень больших усилий многих очень неглупых специалистов: бухгалтеров, аудиторов, экономистов, менеджеров и только потом программистов.

Что же касается промышленных систем, то это вообще "глухая" область для подбых разработок ибо многообразие производственных схем организации управленческих и учетных процессов поистине необъятна. Любая "паттерная" или подобная конструкция неминуемо приведет к жестким ограничениям, сводящим на нет всю эффективность от ее внедрения. Управление, скажем, в пищевой или легкой промышленности в корне может отличесться от машиностроительной, а обе они мало имеют общего с фармацевтикой. Общее, что у них есть - это бухгалтерия и в какой-то степени учет материальных запасов, но это как раз вполне решается 1С. А вот подготовка производства, перспективное и оперативное управление, диспетчирование производственных процессов, логистика и другие производственные проблемы поддаются универсализации очень и очень сложно. Можно сказать и так: нет двух предприятий, выпускающих приблизительно одну и ту же номенклатуру изделий, у которых вышеперечисленные задачи решаются одинаково. Есть общее, конечно, но есть и масса нюансов, присущих каждому из предприятий, в подавляющем большинстве случаев обоснованных чисто человеческим фактором.

Хотя, конечно, не все так уж плохо. Существует на сегодняшний день достаточно много действительно неплохих решений, причем в весьма широком ценовом диапазоне. Однако внедрение этих решений нигде не является панацеей и "специфику" все равно приходится делать "ручками" или вести собственные разработки.

> MsGuns © (20.12.08 19:42) [15]

> Любая "паттерная" или подобная конструкция неминуемо приведет
> к жестким ограничениям

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

Паттерны - это своего рецепты как готовить программу. Можно готовить по своему, но со временем рецепт готовки все равно придет к паттерну, как наиболее удачному варианту.

Например, есть задача которая "висит" уже около года "Расчет технико-экономических" показателей. Были две попытки что-то придумать но они пришли к краху. Для этой задачи нужна уж очень большая гибкость.
На данный момент экономисты решают ее в екселе. Очень много листов, данные в которых хаотически ссылаются одни на других. В таблицах (листах) перемешаны входные данные, нормативы, расчетные данные. Если что-то не устраивает, то в нужной ячейке формула меняется на значение или на другую формулу.
Вот возникла идея создать компонент таблица. Ее мы можем редактировать. После редактирования она посылает системе сообщение "меня редактировали" и остальные таблицы сами пересчитываются. Изменять структуру (вид) таблиц не хотелось бы очень, ведь экономисты привыкли к своим стандартным формам, калькуляциям и т.д.
Это пока все очень абстрактно и непонятно, например, как таблицы должны знать друг о друге и т.д.
Надо брать карандаш в руки и рисовать

>DVM © (20.12.08 20:28) [16]

Можно я не буду благодарить за объяснение слова "паттерн" ?
Спасибо.

Дело в том, что шаблон, образец, оболочка и т.д. суть всего лишь СРЕДСТВО для решения, но никак не само решение. Вся проблема в том, чтобы найти правильное РЕШЕНИЕ, а вот уже реализовать его - это зачастую уже дело техники.
Вот есть такая задачка - расчет ПЛАНОВОЙ себестоимости изделия. Так вот на сегодняшний день я не знаю ни одного удовлетворительного УНИВЕРСАЛЬНОГО решения этой задачки. Старые "проверенные" методы, основанные на советской стабильности с ее госпланом, госкомцен, госснабом и прочими, сегодня ну никак не работают, давая ответы "плюс-минус валяльно-суконная фабрика".
Самое интересное, что задачка с математической точки зрения явно не бином Ньютона, однако предложить, а главное, ЗАСТАВИТЬ всех пользоваться новой, более экономически гибкой системой,- задача сверхсложная, требующая коренной перестройки всей системы управления предприятием. А на это руководители отваживаются крайне редко.

> MsGuns ©

> Можно я не буду благодарить за объяснение слова "паттерн"
> ?

Можно, тем более что паттерны проектирования тут вообще не причем.

> zorik ©

Попытки создать абсолютно гибкие и абсолютно универсальные программы - это утопия. Нельзя создать программу, в которой раз и навсегда будет учтено все.

Я вообще не понимаю, в чем ваш вопрос. То разговор идет о вещах совсем глобальных (типа как правильно начать проектирование программного комплекса), то о частностях каких то ("Вот возникла идея создать компонент таблица").

Вопроса конкретного нет, а так размышления. Всем спасибо! )

Проектирование бизнес-логики работы с БД Найти похожие ветки