有没有人使用 Gupta(以前的 Centura)Team Developer 的经验?
如果是这样,您如何看待它支持开发成熟、可扩展、可维护的应用程序的能力?
谢谢
有没有人使用 Gupta(以前的 Centura)Team Developer 的经验?
如果是这样,您如何看待它支持开发成熟、可扩展、可维护的应用程序的能力?
谢谢
从 1.1 版开始,我一直在使用 CTD。目前我仍在使用 2.1 PTF4,主要用于在 windows 98-Vista 下针对 Centura SQLBase、MS Sql Server 或 MS Access 进行富客户端 CRUD。我没有从2.1升级到较新的版本,所以只能说说2001年以来比较老的2.1。(§)
我们的应用程序通常有大约 150 个窗体窗口,大量使用类(在 2.1 中仍称为“用户定义的变量”)并集成了 MS Office。我们没有稳定性问题或内存泄漏。不过,开发环境有点长:没有智能感知,没有智能调试,没有鼠标几乎无法使用。这可能随着新版本而改变。
CTD 本质上没有任何东西会迫使您编写不可维护的代码。如果您将代码设计为可重用的,那么使用类和文件包含可以在代码中获得良好程度的可重用性,也就是说。可维护性的问题可能是 CTD 变量和类没有访问修饰符,如“private”或“protected”。另外:没有接口或抽象类。另一方面:多重继承。
代码的“大纲结构”需要一些时间来适应,但当我迷失在一个到处都是变量声明和事件处理程序的庞大 C# 文件中时,我什至有时会错过大纲结构......
2.1 的控件非常完整,但我们仍然必须手动集成“现代”的东西,如工具栏、日期选择器或选项卡控件。OTOH,它甚至有一个开箱即用的数字输入字段。其中一份 Unify-Newsletters 表示,他们添加了很多吸引眼球的东西,让应用程序看起来更加最新。表格窗口的 mtable-Extensions 非常有用,可在此处获得:MICSTO 的 MTable。集成第 3 方 DLL(例如用于集成智能卡读卡器)并不是很有趣,尤其是当它们使用结构时。哦:而且“Centura Report Builder”是一种皇家痛苦。
一个很大的优点是与 CTD 一起提供的 SDK:这使得将自己编写的工具集成到开发环境中变得非常容易,例如用于代码生成。
底线:我们使用并且仍在使用 CTD 来开发可扩展和可维护的应用程序。由于不寻常的大纲结构,学习曲线可能有点陡峭,并且可能导致粗心大意地编写“丑陋”的代码:例如大量静态函数、“消息操作”中的大量代码以及变量范围的问题。我认为您使用 CTD 的成功将取决于您要编写的应用程序的性质:对于富客户端 CRUD,您几乎可以肯定比使用 .net 更好,对于我真的不知道的网络应用程序。
请记住,所有这些都与 8 年前的 CTD 2.1 版本有关。现在情况可能完全不同。如果可以,请获取评估版。
编辑:除了语言本身的利弊之外,您可能还想考虑 CTD 是一个利基市场。免费工具不多,我还没有找到一个充满活力的社区(有一个新闻组,但合并后服务器宕机了——也许它还在某个地方)。因此,在特定问题上搜索帮助可能并不容易。
(§) 我没有继续从 2.1 到 5.1 的升级路径,因为在与 Unify 合并后,他们希望只为他们的支持计划(称为 GLS)的订阅者提供补丁。由于我不打算为错误修复付费,我决定继续为我们的旧应用程序使用 2.1,并为新应用程序切换到 .net。我想他们后来修改了这个。
我已经与 Team Developer(以前的 Centura Builder、SQL Windows 等)合作了 9 年。与斯蒂芬凯勒在他的综合回答中描述的版本 2.1 相比,IMO 的事情并没有太大变化。
我工作的公司目前正在使用 TD 5.1 版本,并考虑明年升级到 TD 5.2。我们正在开发一个商业软件产品,针对 Oracle 数据库运行。该应用程序有 500 多个表单窗口和数百个报告。
我认为 Team Developer 可以很好地扩展到简单的小型应用程序,以及具有大型 RDBMS 和数百名用户的大型企业应用程序套件。
代码大纲使 IDE 易于使用,我认为学习曲线不会那么陡峭。即使没有鼠标也可以进行代码编辑,因为有许多方便的键盘快捷键。当然,窗口设计者需要鼠标。在较新的版本中还有一个内置的 Active Coding Assistant。
最新版本(5.1 和 5.2)提供了一些新的 GUI 控件,例如日期/时间选择器、网格窗口(对广泛使用的表格窗口的增强)和富文本编辑器。还有一个新的选项卡控件。菜单可以像丝带一样显示,尽管这不是“真正的”丝带栏。可以在 Unify 网站上找到示例屏幕截图。
TD 5.x 版本中还引入了新的 GUI 主题,为应用程序提供更现代的外观和感觉。
TD 5.x 版本存在许多稳定性问题、性能问题和屏幕绘制等问题。较早的 3.x 和 4.x 以非常强大的质量着称,只有非常有限的数量(如果有的话)稳定性或其他问题。这些问题在统一支持论坛上得到了积极讨论。其中许多问题与数据库路由器(Oracle、MS SQL Server)或 Windows API 调用有关。TD 的基本功能通常运行良好。
也可以在支持论坛上获得有关特定问题和疑问的帮助。开发者社区可能很小,但非常活跃。
我的公司多年来成功地使用了 Team Developer(我们的大多数应用程序都是用 2.0 编写的,其中一些在 5.2 中作为 Web 应用程序编写)并且计划将我们的开发更改为 6.0 版。
来自 C++ 背景,我首先必须找到进入该语言的方法(我仍然想念一些特性,如封装、结构良好的错误处理1或变量范围2)
但毕竟,我学会了忍受语言的限制,并且通过一些纪律,我们的应用程序相对容易维护。(注意:我们有一组基础应用程序一起工作,并使用相同的代码库和一些与客户相关的变体来为每个客户构建单独的版本 - 错误修复出现在公共代码库中(然后用于任何其他项目), lokal 项目文件中的特殊修改)。您只需要为您的项目设置一些基本准则并保留它们,因为编译器不会强制执行它们。
1您只能在它发生的那一点或整个程序的全局范围内捕获一个 sql 错误。
2我仍然有时会遇到拼写错误的变量在完全独立的窗口中编译某些东西的情况 - 或者半引用句柄共享相同名称但不同数据类型的编译器错误
我们将 TD 用于几个大型应用程序,但由于缺乏资源、过时的 SAL 语言和老化的运行时,我们使用 ice tea group gupta/unify 迁移工具将数百万行 SAL 代码和数千个表单迁移到 C# 和 Visual Studio 2010 .
起初我们持怀疑态度。但是现在我们有了全新的应用程序,与我们的其他 .NET 资产完全集成,只需一小部分重写所需的时间。而且我们不必试图理解所有代码在做什么。:) 转换几乎是完美的!
忘了提一下,我们自动将 1200 多个报表生成器报表转换为水晶报表 .NET,这可能节省了一个世纪的无聊工作。