3 多年前，我们被要求为客户开发 EDI 解决方案作为紧急事项。
他们想要解决方案的完整 IP/控制等，并且不想使用免费的开源解决方案、为 BizTalk 等支付大笔资金或向 VAN 支付经常性费用。
我们当时做了一些研究，实际上并没有找到很多关于 EDI 格式、解析等的信息，所以我们的 2 人开发团队直接介入并在 C#/ASP.Net 中开发了一个解决方案。由于将发生的 EDI 消息事务数量很少（每天大约 100 个），我们采用了 RegEx 流程来解析、验证和插入数据库。这是通过一个单独的 C# 应用程序完成的，该应用程序计划每隔几分钟运行一次，并连接到客户端各种提供商 FTP、AS2、EBMX 通信和下载数据以及上传任何出站 EDI 消息。
然后，我们开发了一个网络前端，允许客户员工通过各种收入报告完全访问数据，控制数据以及允许一些客户代理登录并与数据交互并启动发票交易也。
客户现在希望为他们的业务的另一条途径完成更多的 EDI 工作，然而，这一次 edi 消息事务将跃升至 1000 多个。我们的开发团队关注的是 RegEx 的使用。我最近读到，使用 RegEx 进行 EDI 解析会产生巨大的开销，应该避免。
我们最初采用它的唯一原因是缺乏经验，不知道什么是最好用的。也就是说，RegEx 使管理 edi 消息模板变得轻而易举，包括模板内的验证。客户在他们的书籍中添加了更多提供者，我们能够在几分钟内添加新的消息模板（带有自定义更改）。
经过最近的更多研究，我们发现大多数解决方案都将 EDI 文件解析为 XML。是否有一个原因？这只是为了采用更常见的格式和/或避免数据库访问吗？仅通过平面文件 EDI 消息解析 XML 是否更快？
我们希望 EDI 文件中的数据元素在数据库中吗？我们是否只解析 XML 文件？这不只是另一个可以避免的处理步骤吗？
我为我的问题的一般性质道歉，但我很难找到答案。
非常感谢您的时间。
注意：我们的开发团队仅使用 Microsoft 产品，因此请在提供反馈时考虑到这一点。