关于在 Delphi 中分离数据访问、业务逻辑和 GUI 的任何建议
我想将数据层与业务逻辑分开，并将业务逻辑与 GUI 分开。 深入网络后，我偶然发现了一些资源，但仍然无法理清思路。 有些人谈论模式，有些人则指出各种框架。 我的要求是：
- 操作来自rdbms（主要是mysql）的数据，
- 处理id生成的CRUD操作（我应该使用自动增量或提供的数据引擎或生成的pascal代码）
- 表关系可能是逻辑的（不使用引用完整性）或不需要
- 能够从数据模型生成对象关系
- 数据必须转换为业务对象，并且
- 应该使用业务逻辑操作现有的 GUI 组件或免费软件组件
我需要的是：
- 一些带有基本示例代码/应用程序布局的指导技术/建议（例如单元类-模块目录）...作为不是 OOP 专家，当我必须设计类层次结构、
- 带有教程的简单框架
- 甚至是您自己的日常代码/框架/方法时，我会感到困惑
I want to separate data layer from business logic and business logic from GUI. Diving into web I stumbled upon a few resources but still unable to make my mind clear. Some people talk about patterns some others point various frameworks.
My requirements are :
- manipulate data from rdbms (mysql mainly) CRUD operations
- dealing with id generation (should I use autoincrement or data engine supplied or pascal code generated)
- table relations may be logical (no referential integrity is used) or not
- need for ability to generate object relations from data model
- data must be converted to business object and business logic manipulated
- existing gui components or freeware ones should be used
What I need is :
- some guiding techniques / suggestions with basic sample code / application layout (such as units-classes-modules-directories) ... Being not an expert in OOP I get confused when I have to design the class hierarchy
- a simple framework with a tutorial
- or even your own daily code/framework/approach
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
由于您使用的是 Delphi，因此请确保查看 DataModules。 这是放置数据库访问组件和逻辑的地方。
将类放在普通的“Unit”文件中。
让 UI 与这两者对话以使事情发生。 您可以直接在表单上使用数据库访问组件，但这最好以“仅显示”模式完成，并使用数据模块对数据进行操作。 （您可以在基本应用程序的表单上执行所有操作，但如果您想要模块化应用程序，则将其分开是明智的）。
Since you are using Delphi, make sure you look at DataModules. This is where you put your database access components and logic.
Put classes in plain "Unit" files.
Make the UI talk to these two for making things happen. You can use database access components direct on the form, but this is best done as a "display only" mode and using the datamodule to do the operations on the data. (You can do everything on the form for basic apps, but if you are wanting to modularise the app, keeping it apart is sensible).
帮助实施这种分离的一种简单方法是为业务逻辑编写单元测试。 除了其他（实质性）好处之外，使代码可测试意味着它不能（有意或无意）与 UI 紧密耦合。
我尝试（但并不总是成功）通过使用 ClientDataSets 将数据层的详细信息分开，无论后端使用什么（通常是 DBExpress 或 DBISAM）。 我还尝试至少编写一些集成测试，以确保数据层按预期工作（具有已知值的单独测试数据库）。
业务逻辑和数据到位（甚至部分到位）后，UI 就更加直接了。 并且可维护。
One simple way to help enforce this kind of separation is to write unit tests for your business logic. Aside from the other (substantial) benefits, making code testable means it can't (intentionally or otherwise) be tightly coupled to the UI.
I try to (but don't always succeed) keep the details of the data layer separate by using ClientDataSets regardless of what's being used in the back end (usually DBExpress or DBISAM). I also try to write at least some integration tests to make sure the data layer works as expected (separate test database with known values).
With the business logic and data in place (even partly), the UI is much more straight forward. And maintainable.
看看 tiOPF
Take a look at tiOPF
我个人使用 tiopf 作为商业模式。 Tiopf 提供数据访问层。 存储库中的最新代码包括一个类似于 MVC 的 model-gui-mediator 框架，用于显示模型。 这允许您使用标准的 delphi 组件显示数据。
Tiopf 还包括许多 ID 生成器（guid、32 位和 64 位整数等）。
如果您对 tiopf 感兴趣，我建议您首先查看我的概述 。 然后将任何问题转至新闻组。
Personally I use tiopf for the business model. Tiopf supplies the data access layer. The latest code from the repository includes a model-gui-mediator framework similar to MVC for displaying the model. This allows you to display your data using standard delphi components.
Tiopf also incudes a number of ID generators (guids, 32 bit and 64 bit integers etc).
If you are interested in tiopf, I suggest you start by looking at my overview. Then direct any questions to the newsgroups.
尝试一下开源 InstantObjects，您将始终希望将其用于 Delphi 中的各种数据库编程。
在 IO 中，您必须在其接口中定义整个数据结构，然后它将为您生成必要的代码。
去尝试一下。
至于id生成，相信MySQL会为你生成一个自动递增的id。 不要花时间编码。
Try your hands on open source InstantObjects and you will always want to use this for all kinds of database programming in Delphi.
In IO you will have to define the whole of data structure in its interface and then it will generate necessary code for you.
Just try it.
As for id Generation trust MySQL to generate an auto increment id for your. Don't spend time coding it.
我使用的一种非常有效的方法是尝试承担应用程序中的不同角色，然后像您担任该角色一样进行编程。 例如，当您在数据库后端工作时，甚至不要考虑 GUI。 相反，考虑公开仅处理数据的类和方法。 如果你制作自己的SDK并稍后使用，你会发现维护起来会容易得多。
基于测试的开发是你的朋友。 了解 DUnit，并创建简洁的小测试来测试任何重要的代码。 记录界面以及通过查看充满代码的屏幕而看不到的任何内容。
A method that I use, and works very well, is to attempt to take on different roles from your application, and then program as if you were in that role. For example, when you're working on the database back end, don't even think about the gui. Instead think about exposing classes and methods that just work with the data. If you make your own SDK that you will later consume, you will find that maintenance of this will be much easer.
Test based development is your friend. Get to know DUnit, and create small concise tests to exercise any non trivial code. Document the interfaces, and anything that is not apparent by looking at a screen full of code.
我想看看模型-视图-控制器（它是观察者/可观察模式的扩展）。 这意味着“视图”（即UI）只知道如何更新数据，然后响应正在更新的数据。 模型（或可观察）知道如何操作数据并告诉视图它已更新。 这意味着您可以替换 UI，而无需更改数据提供程序，反之亦然。
在 Google 上搜索一下，因为 Delphi 有很多这样的例子（但 Java / C# 等的例子不多）
I would have a look at Model-View-Controller (which is an extension of the Observer / Observable Pattern). This means that the 'view' (i.e. the UI) only knows how to update the data, and then respond to data being updated. The Model (or Observable) knows how to manipulate data and tell Views that it has been updated. This means that you can replace the UI without having to change the data provider, and vice-versa.
Do a search on Google, as there are plenty of examples of this for Delphi (but not as much for Java / C#, etc.)