PowerBuilder初学者问题

发布于 2024-08-07 17:53:02 字数 57 浏览 2 评论 0 原文

我在一家公司担任初级开发人员。我很难理解 PowerBuilder 的概念。有什么好的教程/建议吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

天赋异禀 2024-08-14 17:53:02

嗯，如果我可以重新学习 PB，我会怎么做？

进入 PB 之前，首先要对 SQL 有一个良好的了解。如果你的应用程序要访问数据库，PB 非常擅长，但我年轻时对 SQL 的理解不够好，会导致错误的决策。编写良好的 SQL 将帮助您实现应用程序分区、性能和逻辑集中化。我发现，良好地使用 SQL 可以显着减少“粗糙的鹅卵石 PB 客户端代码”的数量，这些代码往往聚集在通常由经验不足的开发人员编写的数据窗口代码周围。
充分理解 SQL 后，您应该对结果集有一个良好的理解。这是欣赏数据窗口和数据存储的强大功能的一个重要部分。在 PB 中，数据窗口就是一切。我首先将数据窗口简单地用作报告生成器，以了解它如何检索数据，以及它在图形演示控制中为您提供的功能。
发展 PB 脚本的知识。这并不难，但有一些怪癖。了解如何使用PB脚本操作数据窗口，如何使其与其他控件交互。
Sybase 提供 PB 课程。参加一门快速课程，了解如何使用该工具进行操作。如果您的公司希望您学习这一点，但费用太便宜，无法支付专业培训的费用……您可能需要重新考虑您的工作地点。对员工的投资是优秀雇主与平庸雇主的区别。
如果您了解面向对象，这将帮助您编写一个可能更好且更易于维护的应用程序。即使您只能临时拼凑现有的应用程序（欢迎来到我的世界），也可以设计该应用程序的未来增强功能，以引入更好的方法和更少的复杂性。你不可能在一夜之间修复旧的东西，但你可以确保新的东西比旧的东西产生更少的生产支持；如果您可以在保持支持需求水平的同时增加应用程序的功能，那么您在困难的情况下至少赢得了一点胜利。
如果您要继承现有的应用程序，那么提供生产支持是广泛（如果是随机）接触该应用程序的好方法。如果它是一个任何年龄的遗留 PB 应用程序，那么它可能设计不好、编写不好、文档不好，而且不是非常面向对象。在尝试重构之前积累应用程序的经验并熟悉它；其中可能存在各种隐藏的依赖关系。
如果您足够幸运，可以从头开始，那么制作一个原型并从中了解维护一堆代码通过 GUI 对象展开的垃圾是多么混乱。请小心避免围绕数据窗口内置的并发控制支持进行编码，并避免在脚本中嵌入大量 SQL。然后扔掉原型，将业务逻辑整合到PB非可视对象甚至数据库存储过程中；您希望将可重用的业务逻辑放在最集中的位置，并且该位置不是在窗口上的按钮或自定义事件中。

书籍和教程

现在出版的 PB 书籍并不多，但如果您正在做经典的 PB，那么有一本很好的 PB9 高级客户端/服务器开发一书，作者：Bruce Armstrong。
PB手册有很多信息，如果你使用的是Powerbuilder基础类，它已经开源了。您可以从 Sybase CodeExchange 获取它。
那里有一些不错的网站。 Stackoverflow 用户 Terry Voth 有一个很棒的。我也喜欢 Ken Howe 的 PB 技巧网站。
有一些 PB 新闻组提供了很好的信息。还有其他资源；谷歌会在这里为你提供很多帮助。
PowerBuilder Developer's Journal 不再像以前那样有那么多经典的 PB 技巧和示例，但我相信大部分旧内容都可以在网上找到。

随机的事情

我希望你的商店使用源代码控制。如果没有，弄清楚并继续下去。然后查看 PB ORCA 脚本。我开始使用它来自动化我们的构建，它可以节省时间。 PB9 Advanced Client/Server 书中有一章介绍了它，而且 CodeExchange 上也有一些很好的示例。
如果您是新手并且处于枪口之下，您可能会发现自己多次思考，“我可以通过在此处插入嵌入式 SQL 语句来轻松获取数据”。对此要小心；快速点击、单行、仅检索查询可能没问题，但在应用程序中滥用嵌入式 SQL 会使其难以维护。
如果您是新手并且处于困境中，您可能会发现自己多次思考，“我可以通过在检索行或检索结束事件中添加一些代码来使数据看起来像我想要的那样”。对此也要小心。检索行逻辑会损害性能。我见过检索结束逻辑经常用于进行额外的处理并将数据添加到数据窗口；作为数据窗口原始 SQL 语句的一部分，这比通过向数据窗口控制脚本添加更多内容来完成要好得多。
这不仅仅是学习 PB。了解您公司的业务并了解您的系统应该帮助的流程。有时，解决方案的复杂性并不是通过系统自动化来解决的，而是通过让授权方认识到可以首先在业务方面简化流程来解决。
人们对新语言感到非常兴奋；我也不例外，我真的很想利用 .Net 和其他技术做更多事情。但真正发挥作用的是您作为开发人员的承诺；你可以用任何语言做出伟大的事情，无论是 PB、VB、Delphi 还是 .Net。您的选民并不真正知道或关心应用程序是用什么编写的，如果它可以帮助他们完成工作。

Hmmm, if I could learn PB all over again, how would I do it?

Come to PB with a healthy understanding first of SQL. If your app is hitting a database, PB is very good at that, but not understanding SQL well when I was younger lead to poor decisions. Well written SQL will help you with application partitioning, performance, and centralization of logic. I have found that good use of SQL can significantly reduce the amount of "crufty cobble-on PB client code" that tends to congregate around datawindow code commonly written by less experienced developers.
With a good understanding of SQL you should have a healthy understanding of result sets. That's a big part of appreciating the power of the datawindow and datastores. In PB, the datawindow is everything. I'd start by using the datawindow simply as a report maker to drive home how it retrieves data, and the power it gives you in graphic presentation control.
Develop knowledge of PB script. It's not that hard, but it has some quirks. Learn how to manipulate the datawindow with PB script, how to make it interact with other controls.
Sybase offers PB classes. Take one of the fast track courses to get an overview of how to do things in the tool. If your company wants you to learn this but is too cheap to pay for professional training...you may want to reconsider where you work. Investing in employees is what separates the good employers from the mediocre ones.
If you understand object orientation, that will help you write a potentially better and easier-to-maintain app. Even if you're in the position of only being able to cobble-on to an existing app (welcome to my world) then future enhancements to that app can be designed to introduce better approaches and fewer complications. You can't fix the old stuff overnight, but you can make sure the new stuff generates less production support than the old stuff; if you can increase the functionality of the app while keeping support needs level, you've won at least a little victory under difficult circumstances.
If you're inheriting an existing app, doing production support is a good way to get broad, if random, exposure to the app. If it's a legacy PB app with any age on it, it's probably poorly designed, poorly written, poorly documented, and not very object oriented. Build experience with the app and gain familiarity with it before attempting refactorings; there are probably all kinds of hidden dependencies in it.
If you are fortunate enough to be starting from scratch, then make a prototype and learn from it what a mess it is to maintain a pile of crap where code is splayed through GUI objects. Be careful to avoid coding around the datawindow's built-in support for concurrency control, and to avoid tons of embedded SQL in the script. Then throw the prototype away and consolidate business logic in PB non-visual objects or even database stored procedures; you want to put reusable business logic in the most centralized place, and that place is not in a button or custom event on a window.

Books and Tutorials

There aren't many PB books being published these days, but if you're doing classic PB, there is a good PB9 Advanced Client/Server Development book by Bruce Armstrong.
The PB manuals have lots of information, and if you are using the Powerbuilder Foundation Class, it has been open sourced. You can get it at Sybase CodeExchange.
There are some good sites out there. Fellow Stackoverflow user Terry Voth has a great one. I also like Ken Howe's PB tips site.
There are some PB newsgroups with good information. And other resources too; Google will help you a lot here.
PowerBuilder Developer's Journal doesn't have as many classic PB tips and examples as it used to but most of the old content I believe may be available online.

Random Things

I'm hoping your shop uses source control. If not, figure it out and get that going. Then look into PB ORCA Script. I started using this to automate our builds and it's a time saver. There's a chapter in the PB9 Advanced Client/Server book on it, but also some good examples at CodeExchange.
If you're new and under the gun, you'll probably find yourself many times thinking, "I can get that data easy by slapping in an embedded SQL statement here". Be careful about that; quick hit, single row, retrieve-only queries can be ok, but misuse of embedded SQL in your app makes it hard to maintain.
If you're new and under the gun, you'll probably find yourself many times thinking, "I can get that data to look the way I want by throwing in some code in the retrieve row or retrieve end events". Be careful about that too. Retrieve row logic will hurt performance. I've seen retrieve end logic often used to do additional processing and add data to the datawindow; this is much better done as part of the datawindow's original SQL statement rather than by adding more cruft to the datawindow control scripts.
It's not all just about learning PB. Learn your company's business and understand the processes your system is supposed to help with. Sometimes the solution's complexity isn't fixed by automating it with a system, but by getting the authorized parties to recognize that a process can be simplified on the business side first.
People get so worked up about new languages; I'm not an exception and really want to do more with .Net and others. But it is your commitment as a developer that makes the difference; you can do great things in any language, be it PB or VB or Delphi or .Net. Your constituents don't really know or care what the app is written in if it helps them get work done.

回复收藏 0 原文

坦然微笑 2024-08-14 17:53:02

PB只是需要时间。它是面向对象的，所以如果你掌握了这些概念，你就可以更轻松地让它为你工作。如果不把他们打倒。它将使理解产品的整个编程方面变得更容易。

就 IDE 等而言，您很快就会习惯其中的怪癖。如果发生奇怪的事情，请务必查阅互联网，到目前为止，我们已经看到了几乎所有可能发生的事情，有人已经看到了。如果您能找到 McGraw 提供的高级 Powerbuilder 7.0 的副本，我认为它将为未来的概念奠定良好的基础，推荐的 9 本书也很棒。还尝试让您了解 PFC，许多商店都使用它并将继续。它有许多强大的服务，RowSelection、Linkage 等，这将使您的生活变得更加轻松。

当遇到麻烦时保持冷静，并在社区需要时提出很多问题。

祝你好运！