保持 JavaScript 和 C# 对象模型之间的一致性

发布于 2024-08-19 10:39:52 字数 476 浏览 8 评论 0原文

我正在开发一个 ASP.NET Web 应用程序,该应用程序在客户端使用大量 JavaScript 来允许用户执行诸如拖放列表重新排序、查找要添加到列表中的项目之类的操作(如Google 搜索栏)、从列表中删除项目等。

我有一个 JavaScript“类”,用于在客户端存储每个列表项以及有关用户对该项目执行的操作的信息(添加、编辑、删除、移动)。页面发布到服务器的唯一时间是用户完成操作后,即在提交页面之前,我将有关所做更改的所有信息序列化为 JSON,并将其存储在页面上的隐藏字段中。

我正在寻找一些关于如何用 C# 构建我的类的一般建议。我认为在 C# 中拥有一个与 JavaScript 相匹配的类可能会很好,这样我就可以将 JSON 反序列化为该类的实例。不过,在服务器端拥有直接复制 JavaScript 类且仅用于支持 JavaScript UI 实现的类似乎有点奇怪。

这是一个抽象的问题。我只是在寻找在维护匹配的客户端和服务器端对象模型方面做过类似事情的其他人的一些指导。

I'm working on an ASP.NET web application that uses a lot of JavaScript on the client side to allow the user to do things like drag-drop reordering of lists, looking up items to add to the list (like the suggestions in the Google search bar), deleting items from the list, etc.

I have a JavaScript "class" that I use to store each of the list items on the client side as well as information about what action the user has performed on the item (add, edit, delete, move). The only time the page is posted to the server is when the user is done, right before the page is submitted I serialize all the information about the changes that were made into JSON and store it in hidden fields on the page.

What I'm looking for is some general advice about how to build out my classes in C#. I think it might be nice to have a class in C# that matches the JavaScript one so I can just deserealize the JSON to instances of this class. It seems a bit strange though to have classes on the server side that both directly duplicate the JavaScript classes, and only exist to support the JavaScript UI implementation.

This is kind of an abstract question. I'm just looking for some guidance form others who has done similar things in terms of maintaining matching client and server side object models.

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

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

发布评论

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

评论(1

一直在等你来 2024-08-26 10:39:52

很有道理。如果我遇到这个问题,我会考虑使用数据类型或类的单一明确描述,然后从该描述生成代码。

描述可能是一个 javascript 源文件;您可以构建一个解析器,从该 JS 生成适当的 C# 代码。或者,它可能是一个 C# 源文件,而您则执行相反的操作。

您可能会发现在 RelaxNG 中描述它,然后构建(或查找)C# 和 Javascript 生成器有更多实用性。在这种情况下,RelaxNG 模式将被签入源代码控制,而生成的工件则不会。


编辑:还有一个名为WADL的新生规范,我认为这在这方面会有所帮助以及。我还没有评估过 WADL。从外围来看,我知道它并没有席卷全球,但我不知道为什么会这样。 有一个关于此的问题


EDIT2:鉴于缺乏工具(WADL 显然是胎死腹中),如果我是你,我可能会尝试这种战术方法:

  • 在你的 c# 类型上使用 [DataContract] 属性,将这些视为确定的。
  • 构建一个工具,通过在示例 XML JSON 文档上使用 JsonSerializer,从已编译的程序集中提取 C# 类型并实例化该类型,这提供了一种事实上的“对象模型定义”。该工具应该以某种方式验证实例化类型是否可以往返为等效的 JSON,可能会对结果内容进行校验和或 CRC。
  • 运行该工具作为构建过程的一部分。

为了实现这一点,您必须将“示例 JSON 文档”签入源代码,并且您还必须确保是您在各种 JS 代码中使用的形式你的应用程序。由于 Javascript 是动态的,您可能还需要一个类型验证器或其他东西,它将作为 jslint 或其他构建时验证步骤的一部分运行,这将检查您的 Javascript 源以查看它是否正在使用您的“标准”对象模型定义。

Makes perfect sense. If I were confronting this problem, I would consider using a single definitive description of the data type or class, and then generating code from that description.

The description might be a javascript source file; you could build a parser that generates the apropriate C# code from that JS. Or, it could be a C# source file, and you do the converse.

You might find more utility in describing it in RelaxNG, and then building (or finding) a generator for both C# and Javascript. In this case the RelaxNG schema would be checked into source code control, and the generated artifacts would not.


EDIT: Also there is a nascent spec called WADL, which I think would help in this regard as well. I haven't evaluated WADL. Peripherally, I am aware that it hasn't taken the world by storm, but I don't know why that is the case. There's a question on SO regarding that.


EDIT2: Given the lack of tools (WADL is apparently stillborn), if I were you I might try this tactical approach:

  • Use the [DataContract] attributes on your c# types and treat those as definitive.
  • build a tool that slurps in your C# type, from a compiled assembly and instantiates the type, by using the JsonSerializer on a sample XML JSON document, that provides, a sort of defacto "object model definition". The tool should somehow verify that the instantiated type can round-trip into equivalent JSON, maybe with a checksum or CRC on the resulting stuff.
  • run that tool as part of your build process.

To make this happen, you'd have to check in that "sample JSON document" into source code and you'd also have to make sure that is the form you were using in the various JS code in your app. Since Javascript is dynamic, you might also need a type verifier or something, that would run as part of jslint or some other build-time verification step, that would check your Javascript source to see that it is using your "standard" objbect model definitions.

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