在Delphi中主要侧重于数据库开发的OOP从哪里开始?[英] Where to start OOP in Delphi mainly focusing on database development?

本文是小编为大家收集整理的关于在Delphi中主要侧重于数据库开发的OOP从哪里开始?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我想将数据库代码与GUI设计隔离.在合理的时间里 我真的很难设计可重复使用的对象层次结构/框架. Delphi是RAD的绝佳工具,但是当您想以不同的方式解决内容时,文档似乎无效.我想将一些持久性王者开发为数据访问和接线数据,并轻松地将其列入对象/对象列表中.并以多功能方式集成数据显示(使用现有组件dbaware,请为多种格式创建导出/导入例程).我应该从哪里开始?您知道有代码的教程吗? 例如,Delphi安装中包含的MASTAPP演示是Rad-Way作为启动的绝佳来源.我需要OOP中的等效:)带有评论和教程

推荐答案

嗯.大问题,这些东西不在手册中:(真的需要一本书来回答它.但是,如果您要启动一个新的大型项目?然后我的建议清单,在与Delphi进行了10年之后,将开始如下:

通常

在开始使用版本1所需的功能之前,请先考虑一下.但是不要忽略版本2和3的铃声和哨声的概率.

.

除非在简单的单独实用程序或基本数据输入屏幕中,

推理:

  • 他们立即打破您的GUI <->数据库分离.
  • 他们让您对用户友好测试有所失望.
  • 他们鼓励意大利面条代码

请勿使用任何标准或第三方控件,包括表格,框架或数据模块.首先构建自己的派生类库 - 即使您在开始时不添加任何功能,并始终使用这些类.

推理:

  • 完全控制您的应用程序行为.
  • 简化了前瞻性兼容性.
  • 授予您完全自由,可以在新组件树中的任何时刻引入新属性/函数,而无需编辑所有对话和表单或对象.

尽可能地将所有内容创建为具有属性的对象,这些属性只有只有不能才能读取,并且仅读取它们.纪念自己的自我始终使用自己的属性 - 使用快速公共变量作弊通常会始终导致您以后将其重新创建为属性.

数据库设计 - 阅读一本书:)

gui <->数据库分离.

由于应用程序将必须与数据进行交互,然后100%分离,我认为不可能.相反,您的基线对象可能至少定义:

  • 检索或加载数据的机制
  • 编辑该数据的机制
  • 保存数据的机制
  • 显示数据的机制.

这个我会称呼松散耦合.

对于每个数据表或一组密切相关的表组创建一个单独的数据模块,其中包含仅读取查询,可写入的查询等.保持SQL尽可能简单 - 我在2天内将我的最后一个应用程序从Oracle转移到MySQL -150个表 - 150个表使用相关对象并编辑帧:).最初也将它们全部链接到一个合并的连接中.

听起来您已经意识到列表,尤其是TobjectLists是您的朋友.同样 - 为所需的每种对象得出自己的范围.我实际上将真实列表隐藏在更简单的对象中.公开项目和计数属性是微不足道的.然后,您可以根据需要在基本项目中添加更多功能.从那里的列表列表是一个简单的步骤,几乎自然地遵循它们代表的数据库数据的结构.

通过实际存储应用程序中不同部分在数据库中使用/需求的列表的类型,您可以更加复杂.然后,您可以即时创建正确的列表,而无需应用程序实际知道其中的内容 - 在开发阶段,列表和对象本身应包含他们操纵/加载/保存并显示自己的数据所需的所有功能:).这也可以扩展到列表执行的功能.我使用几个基本列表类型,这些类型暴露了简单的计数和项目 - 在我的情况下,这些类型大约有50个后代.

以这种方式工作您的项目可能会积累大量文件,但是您可以依靠并信任Delphi- OO模型非常强大,很少被抓住.

如果您关注大部分的主要应用程序最终是列表加载程序,那就是:)在我的最新功能中,主要功能仅占据约100行代码,但它启动的内容非常复杂.

最后 - 所有这些都是工作:(第一次做正确的事情只是不会发生,让我们诚实,因此请准备好妥协您美丽的对象模型以使该应用程序在门外,但在哪里发表重大评论.以及为什么您这样做以及如何稍后再纠正.

祝你好运:)

其他推荐答案

如果您真的想编写自己的对象持久框架,我强烈建议您在上阅读文档./a>网站.特别是概念手册.

在阅读此文档时,您可能也有兴趣实际使用TIOPF.这是一个稳定且强大的持久性框架,可以与所有主要数据库一起使用.

其他推荐答案

delphi具有许多数据库控件,非常适合RAD,但很难将数据库从GUI中解释.

您可以使用客户端数据集(MIDAS)进行内部通信.它们可以与数据意识控件一起使用,并具有许多其他有趣的属性.

本文地址:https://www.itbaoku.cn/post/597753.html

问题描述

I want to isolate database code from GUI design. For a reasonable time I've been reading/searching/skimming on topics like mgm/mvp/mvc/persistence/objects etc. I really have difficulty in designing a reusable object hierarchy/framework. Delphi is a great tool for RAD but when you want to work things out in a different way the documentation seems ineffective. I want to develop some king of persistence for data access and wiring data into an object/object list easily. And to integrate data display in a versatile manner (using existing components dbaware or not, create export/import routines for multiple formats). Where should I start? Do you know any tutorials with code? For example mastapp demo included in Delphi installation is a great source for RAD-way as a startup. I need the equivalent in OOP :) with comments & tutorial

推荐答案

Hmmm. Big question, this stuff is not in the manuals:( Would really require a book to answer it. However if you are starting a new largish? project then my advice list, after 10 years doing this with Delphi, would start as follows:

Generally

THINK HARD before you start what functionality you need for version 1. But don't ignore the probability of the bells and whistles of versions 2 and 3.

Do not use data aware controls except in simple separate utility or base data entry screens.

Reasoning:

  • They immediately break your GUI <-> database seperation.
  • They let you down a bit at the user-friendliness test.
  • They encourage Spaghetti Code

Do not use any standard or 3rd party controls including forms, frames or datamodules NATIVELY. Build your own libraries of derived classes first - even if you don't add any functionality at the start, and always use those classes instead.

Reasoning:

  • Complete Control of your application's behaviour.
  • Simplifies forward compatiblility.
  • Grants you complete freedom to introduce new properties/functions at any point in your new component tree without having to edit all your dialogues and forms or objects.

As far a possible create everything as an object with properties that have getters where you hide complexity and setters only if they can't be read only. Discipline your self to always use your own properties - cheating with a quick public variable will normally always result in you re-creating it as a property later.

Database design - read a book :)

GUI <-> database separation.

As the Application is going to have to interact with the data then 100% separation I don't think possible. Instead your Baseline Objects will probably define at minimum:

  • A mechanism to retrieve or Load data
  • A mechanism to Edit that data
  • A mechanism to Save the data
  • A mechanism to display the data.

This I would call Loosely-coupled.

For each data table or group of closely related tables create a separate Datamodule with read-only queries, writeable ones etc. Keep the SQL as simple as possible -I moved my last app from Oracle to MYSQL in 2 days - 150 tables with related objects and edit frames:). Link them all to one pooled connection initially also in it's own Datamodule.

It sounds like you have already realised that lists, particularly TObjectLists, are your friends. Again - derive your own for each type of Object you need. I actually hide the real lists inside simpler objects. Exposing the Items and Count properties is trivial. Then you add more functionality to the base item using the internal list as necessary. From There Lists of Lists are a easy step and almost naturally follow the structure of the database data that they represent.

You can get more sophisticated with this approach by actually storing the types of the lists that different parts of your application uses/needs in the Database as well. Then you can create the correct lists on the fly without the application actually knowing what is in them - the lists and objects themselves should by that stage of your development contain all the functionality that they need to manipulate/load/save and display their own data:). This can also be extended to the functions that a list performs. I use a couple of base list types that expose simple count and items - in my case these have about 50 descendents.

Working this way your project may accumulate a large number of files but you can rely on and trust Delphi - the OO model is very strong and rarely gets caught out.

If you follow most of this your main application ends up being a list loader and that is about it :) In my latest the main functionality only occupies about 100 lines of code yet what it launches is pretty complex.

Lastly - All this is lot of work :( Getting it right first time just will not happen let's be honest, so be prepared to compromise your beautiful object model to get the app out-the-door, but make BIG comments where and why you did it and how to correct it again later.

Good luck :)

其他推荐答案

If you really want to write your own object persistence framework, I highly recommend reading the documentation on the tiOPF website. Especially the concepts manual.

While you are reading this documentation you might also be interested in actually using tiOPF. It is a stable and robust persistence framework that can work with all major databases.

其他推荐答案

Delphi has quite a few database controls, which are great for RAD, but its harder to decouple database from Gui.

You can use client datasets (midas) for internal communication. They can be used with data aware controlls and have lots of other interesting properties.

相关标签/搜索