独立于编程语言的模型验证

发布于 2024-10-21 20:01:13 字数 275 浏览 2 评论 0原文

假设您在基础设施中使用多种不同的编程语言和框架来处理大量流量等。

示例堆栈:

  1. 事件驱动的 API 服务器(使用 Scala、node.js、Ruby EM)、
  2. 标准的全堆栈 Web 应用程序(例如 Rails)
  3. (可能更多技术)

当使用不同的语言和框架时,我通常最终会重复大部分模型验证,因为每个“客户入口点”都需要验证其输入。保持同步当然很痛苦。

如果没有像 CORBA 这样的东西,你会如何处理这个问题?

Let's say you use several different programming languages and frameworks in your infrastructure to handle large amounts of traffic etc.

Example Stack:

  1. event driven API servers (using Scala, node.js, Ruby EM)
  2. a standard full stack webapp (e.g. Rails)
  3. (maybe more technologies)

When using different languages and frameworks I usually end up duplicating most of the model validations because every "customer entry point" needs to validate its input. This is of course a pain to keep in sync.

How would you handle this without something like CORBA?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(4

违心° 2024-10-28 20:01:13

最好的选择是一个允许您以与语言无关的格式(例如 JSON)指定模型验证的框架。您最终可能会得到某种验证模式,例如:

{
  "name": [
    {
      "validate": "length",
      "minLength": 6,
      "maxLength": 10
    },
    ...
  ],
  ...
}

然后您将拥有可以解析此格式的特定于语言的验证器。验证器只需要编写一次,然后您就可以为每个模型维护一个模式。

然而,这可能听起来很像 CORBA/SOAP/Thrift/ProtocolBuffers/等等。在此刻。这是因为它们是为了解决这些类型的问题而编写的,如果您自己编写它,您最终将重新发明一些轮子。

Your best bet would be a framework that allows you to specify model validation in a language agnostic format, like JSON. You might end up with a validation schema of sorts, say:

{
  "name": [
    {
      "validate": "length",
      "minLength": 6,
      "maxLength": 10
    },
    ...
  ],
  ...
}

You would then have language-specific validators that could parse this format. The validators only need to be written once, and then you maintain a single schema for each model.

However, this is probably sounding a lot like CORBA/SOAP/Thrift/ProtocolBuffers/etc. at this point. That's because they were written to solve these types of problems, and you'll end up reinventing a few wheels if you write it yourself.

埋情葬爱 2024-10-28 20:01:13

我会继续阅读正则表达式“词典”。
您计算的所有语言都支持正则表达式 - 并且 - 将它们的字符串表示形式从一种语言转换为另一种语言可以通过将表达式本身通过正则表达式传递来完成......

据我观察 - 与编写解析相比,工作量要少得多以及每种语言的执行机制...

就像之前建议的那样 - 您可以以不可知的格式保存这个 Reg-Exps“字典”,例如 JSON。
这将重复工作的范围缩小到 -

  • 您为每种编程语言维护的验证表达式的一个源文件
    • 从主文件转换为目标语言的格式
    • 细化机制
      1. 读取 JSON,
      2. 从中选择配置的检查
      3. 执行它们
    • 边缘情况(如果有)

玩得开心:)

I would go on a "dictionary" of Regular Expressions.
Regular Expressions are supported by all the languages you counted - and - translating their string representation from one language to another can be done by a passing the expressions themselves through regular expressions...

To my observation - it's a lot less work then composing a parse and execute mechanism for each language...

Like advised before - you can save this "dictionary" of Reg-Exps in an agnostic format, such as JSON.
This narrows down the duplicated work to -

  • one source file of validation expressions that you maintain
  • per programming language:
    • converter from the main file to the format of the target language
    • thin mechanism of
      1. reading the JSON,
      2. selecting from it the configured checks
      3. executing them
    • edge cases (if any)

Have fun :)

荒芜了季节 2024-10-28 20:01:13

要添加到 @Nathan Ostgard 的帖子,XML、XSD 以及必要时的 XSLT 也可能有效。这样做的优点是 a) XSD 内置了简单的验证 b) 大多数语言对此都有良好的支持 c) 您不必在每种语言中编写验证;模式中未处理的内容可以在 XSLT 中编写一次(需要注意的是,XSLT 实现往往会有所不同:))

To add to @Nathan Ostgard's post, XML, XSD and, when necessary, XSLT might work as well. The advantage to this would be a) XSD has the simple validation built into it b) most languages have good support for this c) you wouldn't have to write validation in each language; stuff that isn't handled in the schema could be written once in XSLT (with the caveat that XSLT implementations tend to vary :) )

心意如水 2024-10-28 20:01:13

如果您想采用完全验证的方式,我会使用 SOAP。至少,只要您有 SOAP 库,您只需提供接口的 WSDL 即可。

If you want to go the way of full validation, I'd use SOAP. At least, as long as you have SOAP libraries, all you need to feed them is the WSDL for your interfaces.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文