为什么 FoxPro 用于 POS 系统？
我正在考虑将当前在 FoxPro 中构建的 POS（销售点）项目升级到 .net。规划的架构相当复杂，所选新技术背后有很多理由。其中一些要求包括能够同时拥有桌面和 Web 前端（其中 Web 前端的功能有限）、与外部网站同步数据以及多个客户端在一台服务器上运行的能力。我当前选择的模型是 MVP 模式，以 Sql Server（可能是 Express）作为数据库，并在表示和服务之间使用 WCF 服务层，以允许远程 UI。
我担心的是，在我的研究过程中，我注意到触摸屏 POS 系统之间似乎有一个共同的主题，即在 FoxPro 中构建它们。
对于这个有点主观的问题表示歉意，但是我很想知道这是否有任何特殊原因？ FoxPro 是否具有适合此类系统的特定开箱即用功能？我没有使用过 FoxPro，因此在最终确定该项目的技术选择之前，我想确保我不会因为完全排除它而错过任何技巧。
I'm looking at upgrading a POS (Point Of Sale) project which is currently built in FoxPro to .net. The planned architecture is quite complex and there is plenty of rationale behind the new technologies chosen. Some of the requirements include the ability to have both desktop and web front end (where web front end has limited functionality), syncing data with an external website and the ability for multiple clients to run off of 1 server. My current model of choice is an MVP pattern with Sql Server (probably Express) as the DB, and a WCF service layer between the presentation and services in order to allow for remote UIs.
My concern is that during my research I have noticed that there seems to be a common theme amongst touch screen POS systems to build them in FoxPro.
Apologies for the slightly subjective question however I am keen to find out if there is any particular reason for this? Does FoxPro have any particular out of the box functionality that lends itself to this type of system? I have not used FoxPro and so before finalising my choice of technologies for this project would like to make sure I am not missing a trick by ruling it out completely.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
可能是因为 FoxPro 是一个 POS。
（我开玩笑，我开玩笑。）
Probably because FoxPro is a POS.
(I kid, I kid.)
许可——SQLserver 在客户端操作系统上运行不佳并且价格昂贵。
Foxpro 既便宜又简单。
如果您所做的只是从一个表中检索价格值并更新另一个表中的销售额，那么 SQL 就有点大材小用了。
Licencing - SQLserver didn't run well on client OSes and was expensive.
Foxpro was cheap and easy.
If all you are doing is retrieving price values from one table and updating sales in another, then SQL is rather overkill.
Foxpro 是一个廉价且快速的数据库。选择它可能是因为它非常符合设计时的要求。
foxpro was an inexpensive and fast database. It was probably chosen because it was a good match for their requirements at the time it was designed.
许多 POS 系统具有独立功能，因此即使与店内服务器的连接中断，商店也可以继续交易。
通常，这意味着用于价格查找等的本地数据库，以及交易数据的本地存储，直到服务器连接再次恢复。
硬件和许可成本需要尽可能低。
因此，几年前，FoxPro 是一个不错的选择，但今天，正确架构的 .NET 应用程序将是一个绝佳的选择。
Many POS systems have a standalone capability so that the store can continue to trade even if the connection to the in-store server(s) is down.
Typically this means a local database for price lookup etc, and local storage of transaction data until the server connection comes back up again.
The hardware and licensing costs need to be as low as possible.
Hence FoxPro was a good choice a few years ago, but a properly architected .NET application would be an excellent choice today.
许多 PoS 系统可以追溯到 SQL 数据库在桌面计算机上流行之前，因此很多人仍然使用 FoxPro 或其他 xBase< /a> 风格的数据库。由于 PoS 系统通常是单用户和单任务，因此通常没有令人信服的理由升级到成熟的 SQL 数据库引擎。
Many PoS systems date back to before SQL databases became popular on desktop machines so very many still use FoxPro or other xBase-style database. As PoS systems are generally single-user and single-tasking, there was very often no compelling reason to upgrade to a fully-fledged SQL database engine.
FoxPro 当时有一些优势。我记得多年来所有新的并发数据库至少都已就位，因此我们一次又一次地选择 FoxPro 作为现在的 POS 解决方案：
仍然存在数量惊人的 FoxPro 遗留应用程序（尤其是中小型公司），因此这不仅仅是 POS 问题。
FoxPro had a few advantages at that time. I can remember that for many many years all the new concurrent DBs laked at least in on place, so we choose FoxPro over and over again for now POS solutions:
There are still an incredible huge number of FoxPro legacy applications (especially in small and medium companies), so this is not just a POS issue.