С чего начать ООП в Delphi, в основном, сосредоточившись на разработке баз данных? - PullRequest
7 голосов
/ 19 июня 2009

Я хочу изолировать код базы данных от дизайна GUI. В течение разумного времени я читал / искал / просматривал такие темы, как mgm / mvp / mvc / persistence / objects и т. Д. У меня действительно есть трудности в проектировании многократно используемой иерархии / структуры объектов. Delphi - отличный инструмент для RAD, но когда вы хотите по-другому разобраться, документация кажется неэффективной. Я хочу разработать некоторый король постоянства для доступа к данным и связывания данных в список объектов / объектов легко. А для универсальной интеграции отображения данных (используя существующие компоненты dbaware или нет, создайте процедуры экспорта / импорта для нескольких форматов). С чего мне начать? Знаете ли вы какие-нибудь учебники с кодом? Например, демонстрационная версия mastapp, включенная в установку Delphi, является отличным источником для RAD-way при запуске. Мне нужен эквивалент в ООП :) с комментариями и учебником

Ответы [ 8 ]

12 голосов
/ 19 июня 2009

Хммм. Большой вопрос, этого материала нет в руководствах :( Для этого на самом деле потребуется книга. Однако, если вы начинаете новый крупный проект? Мой список советов, после 10 лет работы с Delphi, будет выглядеть следующим образом:

В целом

Подумайте, прежде чем начать, какие функциональные возможности вам нужны для версии 1. Но не игнорируйте вероятность наворотов версий 2 и 3.

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

Обоснование:

  • Они немедленно нарушают разделение базы данных вашего GUI <->.
  • Они немного разочаровали вас в тесте на удобство использования.
  • Они поощряют код Спагетти

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

Обоснование:

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

Насколько возможно, создать все как объект со свойствами, которые имеют геттеры, в которых вы скрываете сложность и сеттеры, только если они не могут только для чтения. Дисциплинируйте себя, чтобы всегда использовать свои собственные свойства. Обман с быстрой общедоступной переменной обычно всегда приводит к тому, что вы позже воссоздаете его как свойство.

Дизайн базы данных - почитайте книгу:)

GUI <-> разделение базы данных.

Поскольку приложению придется взаимодействовать с данными, то 100% разделение не представляется возможным. Вместо этого ваши базовые объекты, вероятно, будут определять как минимум:

  • Механизм для извлечения или загрузки данных
  • Механизм для редактирования этих данных
  • Механизм сохранения данных
  • Механизм отображения данных.

Это я бы назвал слабосвязанной.

Для каждой таблицы данных или группы тесно связанных таблиц создайте отдельный модуль данных с запросами только для чтения, с возможностью записи и т. Д. Сохраняйте максимально простой SQL-запрос - я переместил свое последнее приложение из Oracle в MYSQL за 2 дня - 150 таблиц со связанными объектами и редактировать кадры :). Первоначально свяжите их все с одним объединенным соединением также в своем собственном модуле данных.

Похоже, вы уже поняли, что списки, в частности списки TObjectLists, являются вашими друзьями. Опять же - найдите свой собственный для каждого типа объекта, который вам нужен. Я на самом деле скрываю реальные списки внутри более простых объектов. Предоставление свойств Items и Count тривиально. Затем вы добавляете больше функциональности к базовому элементу, используя внутренний список по мере необходимости. Отсюда списки списков являются простым шагом и почти естественным образом следуют структуре данных базы данных, которые они представляют.

Вы можете получить более изощренный с этим подходом, фактически сохраняя типы списков, которые различные части вашего приложения используют / нуждаются также в Базе данных. Затем вы можете создавать правильные списки на лету, при этом приложение не знает, что в них находится - сами списки и объекты должны на этом этапе разработки содержать все функции, необходимые для управления / загрузки / сохранения и отображения собственных данных. :). Это также можно распространить на функции, которые выполняет список. Я использую несколько базовых типов списков, которые показывают простое число и элементы - в моем случае у них есть около 50 потомков.

Работая таким образом, ваш проект может накапливать большое количество файлов, но вы можете положиться и доверять Delphi - модель OO очень сильная и редко попадает в ловушку.

Если вы будете следовать большей части этого, ваше основное приложение окажется загрузчиком списка, и это все :) В моем последнем случае основная функциональность занимает всего около 100 строк кода, но то, что оно запускает, довольно сложно.

Наконец, все это - большая работа :( Правильного понимания с первого раза просто не произойдет, давайте будем честными, поэтому будьте готовы к компрометации вашей прекрасной объектной модели, чтобы получить приложение на улице, но делайте БОЛЬШИЕ комментарии и почему ты это сделал и как исправить это позже.

Удачи :)

5 голосов
/ 19 июня 2009

Если вы действительно хотите написать свою собственную инфраструктуру сохранения объектов, я настоятельно рекомендую прочитать документацию на веб-сайте tiOPF . Особенно руководство .

Пока вы читаете эту документацию, вы также можете быть заинтересованы в фактическом использовании tiOPF. Это стабильная и надежная структура персистентности, которая может работать со всеми основными базами данных.

1 голос
/ 05 октября 2013

Вы также можете рассмотреть hcOPF

1 голос
/ 19 июня 2009

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

Получите несколько хороших книг по шаблонам. Вы найдете их бесценными, продолжая идти по этому пути, и на них будут часто ссылаться. Я предлагаю GOF для основ и Шаблоны архитектуры корпоративных приложений для стороны объектной модели базы данных вещей. Большинство концепций в этих библиотеках основаны на шаблонах, обсуждаемых в этих книгах.

1 голос
/ 19 июня 2009

Jazz SDK Тип значения, рамки OPF и MVP

1 голос
/ 19 июня 2009

Я никогда не делал этого, но ...

Посмотрите на Мгновенные объекты.

Для визуального создания классов / объектов в Delphi попробуйте ModelMaker (коммерческое решение).

1 голос
/ 19 июня 2009

Delphi имеет довольно много элементов управления базами данных, которые хороши для RAD, но сложнее отделить базу данных от Gui.

Вы можете использовать клиентские наборы данных (midas) для внутренней коммуникации. Они могут использоваться с элементами управления с поддержкой данных и обладают множеством других интересных свойств.

0 голосов
/ 20 июня 2009

Если вы ищете каркас, Data Abstract - лучший инструмент, который я знаю для этой вещи.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...