当 UI 组件具有内置功能时，如何将应用程序逻辑与 UI 分开？
我知道将用户界面代码与域代码分开非常重要——应用程序更容易理解、维护、更改和（有时）隔离错误。但这是我的心理障碍...
Delphi 附带的组件具有可以执行我想要的操作的方法，例如，RichText Memo 组件可以让我处理富文本。其他组件，例如 TMS 的字符串网格，不仅可以实现我想要的功能，而且我还为该功能支付了额外费用。这些功能将 R 纳入 RAD。
编写自己的类来完成别人已经为我完成的事情似乎不合逻辑。它正在重新发明轮子[曾经尝试过直接使用富文本吗？ :-) ] 但是，如果我使用这些组件中内置的功能，那么我最终会得到大量混合的 UI 和域代码——我将拥有一个表单，其中大部分代码都内置在其事件处理程序中。
您如何处理这个问题？ ...或者，如果我想继续使用其他人已经为我编写的代码，您建议我如何处理该问题？
I know it's important to keep user interface code separated from domain code--the application is easier to understand, maintain, change, and (sometimes) isolate bugs. But here's my mental block ...
Delphi comes with components with methods that do what I want, e.g., a RichText Memo component lets me work with rich text. Other components, like TMS's string grid not only do what I want, but I paid extra for the functionality. These features put the R in RAD.
It seems illogical to write my own classes to do things somebody else has already done for me. It's reinventing the wheel [ever tried working directly with rich text? :-) ] But if I use the functionality built into components like these, then I will end up with lots of intermingled UI and domain code--I'll have a form with most of my code built into its event handlers.
How do you deal with this issue? ... Or, if I want to continue using the code others have already written for me, how would you suggest I deal with the issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，请记住“处理富文本”不是您的应用程序应该做的事情。您的应用程序应该使用户能够执行特定任务，而处理该任务的代码就是您的域逻辑。如果您的程序需要完成的部分任务涉及使用富文本，那么您可以将该部分委托给富文本组件。正如您所提到的，复杂性来自这些库和域逻辑之间的接口。
Delphi 域逻辑和 Delphi UI 控件相互交互的方式主要是通过事件处理程序。但这并不意味着您需要将域逻辑放入事件处理程序本身。相反，尝试编写包含您需要完成的特定于域的任务的代码的单元，并让事件处理程序调用这些单元。
换句话说，不要编写类来重新发明轮子并做其他人已经为您完成的事情。你说得对，那是不合逻辑的。但是，将您使用的控件和库尚未提供的特定于应用程序的部分编写为自己单独的单元中的单独类，并通过窗体上的事件处理程序和公共方法或属性将它们连接起来，你最终会得到很好的关注点分离。
First off, remember that "dealing with rich text" isn't what your app is supposed to do. Your app is supposed to enable the user to perform a certain task, and the code to take care of that task is your domain logic. If part of the task that your program needs to accomplish involves working with rich text, then you can delegate that part of it to a rich text component. The complexity comes, as you mentioned, at the interface between these libraries and domain logic.
The way Delphi domain logic and Delphi UI controls interact with each other is mostly through event handlers. But that doesn't mean that you need to put your domain logic in the event handlers themselves. Instead, try writing units that contain the code for the domain-specific tasks you need to accomplish, and have the event handlers call those units.
In other words, don't write classes to reinvent the wheel and do things others have already done for you. You're right, that would be illogical. But write the application-specific parts that the controls and libraries you use haven't provided as their own separate classes in their own separate units, and connect them through event handlers and public methods or properties on your forms, and you'll end up with decent separation of concerns.
您可以通过使用带有 clientDataSets 的数据模块来创建相当干净的分离，以包含业务逻辑和数据对象。您甚至可以更进一步，将业务逻辑从数据中分离出来。显然，表单包含 UI。几乎您使用的每个组件都可以进行数据绑定，这使得将它们绑定到您的 clientDataSet 变得很容易。
请记住，Delphi 的做事方式并不总是符合 Java 或 .Net 的最佳实践。您的目标应该是做一些感觉正确且适合德尔福的事情。
You can create a rather clean separation by using datamodules with clientDataSets to contain your business logic and data objects. You could even take it step further and break the business logic away from the data. Obviously the form contains the UI. Almost every component you use can be data bound which makes it easy to bind them to your clientDataSets.
Just remember Delphi has a way of doing things that don't always fit the best practices that Java or .Net have. Your goal should be to do something that feels right and works for Delphi.