有人对 GUI 销售点系统的数据库、编程语言/框架有建议吗？
我们公司有一个销售点系统，有很多附加功能，例如订购和接收功能、销售和订单历史记录等。我们的主要问题是该系统没有从头开始正确设计，因此需要很长时间才能进行修复和修复。处理客户的请求。 此外，由于数据库连接等的多用户许可费用，我们当前使用的技术（Progress 数据库、Progress 4GL 语言）会给我们的客户带来相当多的许可费用。
经过大量讨论后，我们看起来像是可能会从头开始（同时至少暂时维持当前产品）。 我们正在寻找一些东西：
创建具有良好 GUI 前端的系统（目前是 CHUI，并且应用程序的构建方式不允许我们重新设计前端...没有分层或分离业务逻辑和 gui...颤抖）。
创建能够模块化不同功能的系统，这样产品就不必包含所有功能。 这将为我们当前需要基本功能和较低价格标签的客户降低成本。 那些想要的人可以使用附加功能。
使用适当的设计模式使产品易于随时添加或更改任何部分（即更改数据库或更改前端，而无需重写应用程序或其中大部分）。 这在今天是一个问题，因为 Progress 4GL 代码是直接针对数据库编译的。 数据库中的小改动需要大量的代码重新编译。
我们的新系统将基于 Linux，并且客户端应用程序可以提供来自一个或多个 Windows 盒子的功能。
因此，我正在寻找有关有人可能为此类产品推荐哪种数据库和/或框架或编程语言的建议。 任何在这一领域有经验的人都可能能为我们指明正确的方向，甚至对应该避免什么有一些想法。 我们考虑过.NET 和 SQL Express（我们不需要企业级数据库），但这会将我们限制在 Windows 上（据我所知）。 我听说过 Mono 用于在 Linux 环境中编写 .NET 代码，但我对此还不太了解。 我们还考虑了基于 Java 和 MySql 的实现。
总而言之，我们希望做到以下几点：
降低我们将用于开发产品的技术的许可成本（Oracle，哎呀！MySQL，很好。）
提供易于维护和支持的解决方案。
一种解决方案，其组件能够通过 CHUI 前端在“旧”硬件上运行。 （我们的一些客户拥有 40 多个终端，如果要转换为 PC，需要花费大量现金）。
如有建议，我们将不胜感激。
谢谢
[更新] 我应该指出，我们目前正在进行总成本分析。 这个问题旨在为我们提供一些“受过教育的”选项来研究或分析。 任何可以分享有关客户端/服务器设置的经验/建议的人将不胜感激（不仅仅是那些具有销售点系统经验的人......这将是一个额外的奖励）。
[更新]
对于任何感兴趣的人，我们最终选择了 Microsoft Dynamics NAV、LS Retail（用于销售点和其他各种功能的插件），然后做了一些（目前正在研究） ）在此之上进行定制工作。 这种设置为我们带来了额外的好处，即拥有完全集成的 g/l 系统，而这是我们当前系统所缺乏的。
Our company has a point of sale system with many extras, such as ordering and receiving functionality, sales and order history etc. Our main issue is that the system was not designed properly from the ground up, so it takes too long to make fixes and handle requests from our customers. Also, the current technology we are using (Progress database, Progress 4GL for the language) incurs quite a bit of licensing expenses on our customers due to mutli-user license fees for database connections etc.
After a lot of discussion it is looking like we will probably start over from scratch (while maintaining the current product at least for the time being). We are looking for a couple of things:
Create the system with a nice GUI front end (it is currently CHUI and the application was not built in a way that allows us to redesign the front end... no layering or separation of business logic and gui...shudder).
Create the system with the ability to modularize different functionality so the product doesn't have to include all features. This would keep the cost down for our current customers that want basic functionality and a lower price tag. The bells and whistles would be available for those that would want them.
Use proper design patterns to make the product easy to add or change any part at any time (i.e. change the database or change the front end without needing to rewrite the application or most of it). This is a problem today because the Progress 4GL code is directly compiled against the database. Small changes in the database requires lots of code recompiling.
Our new system will be Linux based, with a possibility of a client application providing functionality from one or more windows boxes.
So what I'm looking for is any suggestions on which database and/or framework or programming language(s) someone might recommend for this sort of product. Anyone that has experience in this field might be able to point us in the right direction or even have some ideas of what to avoid. We have considered .NET and SQL Express (we don't need an enterprise level DB), but that would limit us to windows (as far as I know anyway). I have heard of Mono for writing .NET code in a Linux environment, but I don't know much about it yet. We've also considered a Java and MySql based implementation.
To summarize we are looking to do the following:
Keep licensing costs down on the technology we will use to develop the product (Oracle, yikes! MySQL, nice.)
Deliver a solution that is easily maintainable and supportable.
A solution that has a component capable of running on "old" hardware through a CHUI front end. (some of our customers have 40+ terminals which would be a ton of cash in order to convert over to a PC).
Suggestions would be appreciated.
Thanks
[UPDATE]
I should note that we are currently performing a total cost analysis. This question is intended to give us a couple of "educated" options to look into to include in or analysis. Anyone who could share experiences/suggestions about client/server setups would be appreciated (not just those who have experience with point of sale systems... that would just be a bonus).
[UPDATE]
For anyone who is interested, we ended up going with Microsoft Dynamics NAV, LS Retail (a plugin for the point of sale and various other things) and then did some (and are currently working on) customization work on top of that. This setup gave us the added benefit of having a fully integrated g/l system, which our current system lacked.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Java 语言（或者 Scala，如果你想成为“前沿”，取决于你计划如何支持它以及你的开发人员喜欢什么，它可能会更好，但也可能更糟）
H2 用于数据库
Swing 用于 GUI
原因：免费、可移植而且相当标准。
更新：错过了系统应该是客户端-服务器设置的部分。 我的假设是数据库和客户端应该在同一台机器上运行。
Java for language (or Scala if you want to be "bleeding edge", depending on how you plan to support it and what your developers are like it might be better, but also worse)
H2 for database
Swing for GUI
Reason: Free, portable and pretty standard.
Update: Missed the part where the system should be a client-server setup. My assumption was that the database and client should run on the same machine.
我建议您首先更多地研究您的限制 - 您对使用特定类型终端的客户进行了传递参考 - 这可能会限制您的选择，除非客户同意升级。
您需要为此做更多的跑腿工作。 从网络论坛获得意见固然很棒，但我们不可能像您一样了解您的环境。
我的总体建议是瞄准广泛使用的技术。 这样，平台上的专业知识比“利基”技术更便宜，而且如果遇到困难也更容易获得帮助。 当然，如果您已经为客户提供了不可协商的技术，那么遵循此建议可能是不可能的。
我的第二个建议是在选择“从头开始重写”选项之前，完成一个完整的项目计划，其中包含详细的规格和适当的成本估算。 现在，您说重写系统比维护它更便宜，并且您并不真正知道重写会花费多少。
I suggest you first research your constraints a bit more - you made a passing reference to a client using a particular type of terminal - this may limit your options, unless the client agrees to upgrade.
You need to do a lot more legwork on this. It's great to get opinions from web forums, but we can't possibly know your environment as well as you do.
My broad strokes advice would be to aim for technology that is widely used. This way, expertise on the platform is cheaper than "niche" technologies, and it will be easier to get help if you hit a brick wall. Of course, following this advice may not be possible if you have non-negotiable technology already in place at customers.
My second suggestion would be to complete a full project plan, with detailed specs and proper cost estimates, before going with the "rewrite from scratch" option. Right now, you're saying that it would be cheaper to rewrite the system than maintain it, and you don't really know how much it would cost to re-write.
我建议您使用浏览器作为 UI。
将您的应用程序组织为 Web 应用程序。
后端有很多选项。 可以使用Java + MySQL。 Java 后端将使您免于 Windows/Linux 争论，因为它可以在两个平台上运行。 您无需支付 Java 和 MySQL 的任何许可费用。 （编辑：当然还有很多其他语言具有适用于 Linux 和 Windows 的运行时，包括 PHP、Ruby、Python 等）
如果您选择这条路线，您可能还需要考虑 Google Web Toolkit (GWT) 来创建以模块化方式基于浏览器的前端。
不过，请注意一点。 当涉及到内存管理时，浏览器可能会很烦人。 根据我们的经验，这是基于浏览器的 POS 中最重大的挑战。您可能想要查看在浏览器中运行的 Adobe Flex，但其内存管理可能更文明。
I suggest you use browser for the UI.
Organize your application as a web application.
There are tons of options for the back-end. You can use Java + MySQL. Java backend will save you from windows/linux debate as it will run on both platforms. You won't have any licensing cost for both Java and MySQL. (Edit: Definitely there are a lot of others languages that have run-times for both linux & windows including PHP, Ruby, Python etc)
If you go this route, you may also want to consider Google Web Toolkit (GWT) for creating the browser based front-end in a modular fashion.
One word of caution though. Browsers can be pesky when it comes to memory management. In our experience, this was the most significant challenge in doing browser based POS You may want to checkout Adobe Flex that runs in browser but might be more civil in its memory management.
什么是CHUI？ 字符 UI，如 VT 终端？ 或者甚至3270风格？
听起来您需要一个 3 层系统 - 数据库后端、运行大部分后端业务流程的中间层以及用于 CHUI / GUI / 数据网关的前端层。
所有三层都可以驻留在一台机器上； 或者您可以将层分发到不同的服务器。 前端层将控制实际的终端，无论它们是 VT 终端、网络浏览器还是定制编写的“客户端”应用程序。
确保您已经考虑了这里的硬件需求 - 您是否需要条形码扫描仪、现金抽屉、POS 借记/信用卡终端等？ 如果您使用标准浏览器，可能很难可靠地集成这些项目。 （至少，您可能必须编写特殊的小程序来处理它们。）
最后，考虑 Windows 上瘦客户端技术的可能性。 它极大地简化了系统管理，因为您只需集中升级软件。 瘦客户端 PC 很便宜——不到 200 美元。
What is CHUI? Character-UI, as in VT terminals? Or even 3270 style?
It sounds like you need a 3-tier system - the database backend, a middle-layer that runs the bulk of the back-end business processes, and a front-end layer for the CHUI / GUI / data-gateway.
All three layers can reside on one machine; or you can distribute the tiers out to various servers. The front-end layer would control the actual terminals, whether they are VT-terminals, or a web-browser, or a custom-written 'client' application.
Make sure you have considered the hardware needs here -- are you going to have barcode scanners, cash drawers, POS debit/credit terminals, et cetra? If you are using a standard browser, it might be hard to reliably integrate those items. (At the very least, you're likely going to have to write special applets to handle them.)
Finally, consider the possibility of a thin-client technology on Windows. It greatly simplifies system management, since you only have to upgrade the software centrally. Thin-client PC's are cheap -- sub $200.
Golden Code Development（参见 www.goldencode.com）拥有一项技术，可以将 Progress 4GL（架构和代码...整个应用程序）自动转换为具有关系数据库后端（例如 PostgreSQL）的 Java 应用程序。 他们目前支持非常完整的 CHUI 环境，并且他们确实重构了代码。 例如，转换将 UI、数据模型和业务逻辑分离为单独的 Java 类。 整个结果是与原始版本兼容的直接替换（用户不需要重新培训，流程不需要修改，数据也被迁移）。 这是可能的，因为它们提供了一个应用程序服务器和一组提供这种兼容性的运行时类。 自动转换的结果不需要进一步编辑即可编译和运行。 包含真正的终端支持，因此硬件终端仍然可以工作（它需要一个小型 JNI 库才能从 Java 访问 NCURSES）。 运行时中的所有其余代码都是纯 Java。 最终系统中使用了 No Progress Software Corp 的技术，并且在 Linux 上运行。
至少有一个转换后的系统已投入生产，运行 24 x 7 的关键任务环境。 这是一个经过改造的 ERP 系统，他们的中型试点客户使用它来运营整个业务。
Golden Code Development (see www.goldencode.com) has a technology that does automated conversion of Progress 4GL (the schema and code... the entire application) to a Java application with a relational database backend (e.g. PostgreSQL). They currently support a very complete CHUI environment and they do refactor the code. For example, the conversion separates the UI, the data model and the business logic into separate Java classes. The entire result is a drop-in replacement that is compatible with the original (users don't need retraining, processes don't need to be modified, the data is migrated too). This is possible because they provide an application server and a set of runtime classes that provide that compatibility. The result of the automated conversion is not something that needs further editing before you can compile and run it. True terminal support is included so hardware terminals still work (it requires a small JNI library to access NCURSES from Java). All the rest of the code in the runtime is pure Java. No Progress Software Corp technology is used in the resulting system and it runs on Linux.
At least one converted system is already in production, running a 24 by 7 mission critical environment. It is a converted ERP system that their mid-sized pilot customer uses to run their entire business.