在哪里开始OOP在Delphi主要关注数据库开发？ [英] Where to start OOP in Delphi mainly focusing on database development?
问题描述
我想从GUI设计中隔离数据库代码。对于一个合理的时间，我一直在阅读/搜索/ skimming主题像mgm / mvp / mvc /持久性/对象等。
我真的很难设计一个可重用的对象层次结构/框架。 Delphi是一个伟大的RAD工具，但是当你想以不同的方式工作的文档似乎无效。我想开发一些持久性的数据访问和接线数据到一个对象/对象列表很容易。并且以通用方式集成数据显示（使用现有组件dbaware或不是，为多种格式创建导出/导入例程）。我应该从哪里开始？你知道任何教程的代码吗？
例如，包含在Delphi安装中的mastapp演示是RAD-way作为启动的一个很好的源。我需要在OOP :)的等效与评论&教程
嗯。大问题，这个东西不是在手册:(真的需要一本书来回答它，但如果你正在开始一个新的大型项目然后我的建议列表，经过10年这样做与德尔福，将开始如下： / p>
通常
THINK HARD在您开始使用版本1所需的功能之前。
不要使用数据感知控件，除非在简单的单独的实用程序或基本数据输入屏幕中。
推理：
- 他们立即中断了您的GUI数据库分离。 $ b
< b $ b
不要使用任何标准或第三方控件，包括表单，框架或数据模块NATIVELY。首先构建您自己的派生类库 - 即使您在开始时没有添加任何功能，并始终使用这些类代替。
推理：
- 完全控制应用程式的行为。
- 简化向前兼容性。
- 授予您完全自由地在新组件树中的任何位置引入新的属性/对话框和窗体或对象。
尽可能创建一个对象的属性有getters，如果他们不能为只读。
数据库设计 - 读取数据库设计 - 读取数据库a book：）
GUI < - >数据库分隔。
与数据交互，然后100％分离我不认为可能。
- 检索或加载数据的机制
- 修改此数据的机制
- 保存数据的机制
- 显示数据的机制。
这就是所谓的松散耦合。
对于每个数据表或一组紧密相关的表，数据模块只读查询，可写的等。保持SQL尽可能简单 - 我将我的最后一个应用程序从Oracle移动到MYSQL在2天 - 150表与相关对象和编辑框架:)。将它们全部链接到一个池化连接，最初也在它自己的数据模块中。
听起来你已经意识到列表，特别是TObjectLists，是你的朋友。再次 - 为你需要的每种类型的对象派生自己。我实际上隐藏真正的列表里面更简单的对象。公开项目和计数属性是微不足道的。然后根据需要使用内部列表向基础项目添加更多功能。从列表列表是一个简单的步骤，几乎自然地遵循它们代表的数据库数据的结构。
您可以通过这种方法更复杂，实际存储您的应用程序的不同部分在数据库中使用/需要的列表类型。然后你可以在运行时创建正确的列表，而应用程序实际上不知道它们是什么 - 列表和对象本身应该在开发的这一阶段包含他们需要操纵/加载/保存和显示自己的数据的所有功能:)。这也可以扩展到列表执行的函数。我使用几个基本列表类型，暴露简单的计数和项目 - 在我的情况下，这些有大约50个后代。
以这种方式工作，您的项目可能会积累大量文件，但您可以依赖并信任Delphi - OO模型非常强大，很少被抓住。
如果你按照大部分这样，你的主要应用程序最终是一个列表加载器，这是关于它:)在我最新的主要功能只占用大约100行代码但是它发布的是非常复杂的。
最后 - 这一切是很多的工作:(让第一次正确不会发生让我们诚实，所以准备妥协你的美丽的对象模型，让应用程序在门外，但使BIG的意见，在哪里和为什么你做它，以及如何纠正它再次。
祝你好运:)
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 :)
这篇关于在哪里开始OOP在Delphi主要关注数据库开发？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
