Где запустить ООП в Delphi, главным образом фокусирующемся на разработке базы данных?

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

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

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

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

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

Обычно

ПОДУМАЙТЕ, прежде чем начинать, какие функции вам нужны для версии 1. Но не игнорируйте вероятность наворотов версий 2 и 3.

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

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

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

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

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

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

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

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

GUI <-> database разделение.

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

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

Я бы назвал его слабосвязанным.

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

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

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

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

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

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

Удачи :)

Jazz SDK Тип значения, платформы OPF и MVP

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

Взгляните на мгновенные объекты.

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

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

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

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