MVC Web UI 和 API 设计问题 - 一种新的视图模型还是使用现有的视图模型？
我最近遇到了为现有 Web 门户创建 API 的需求。当前的 Web UI 将保持原样，API 将为任何想要在核心应用程序之上构建应用程序的客户提供额外的功能。
Web 用户界面非常复杂，由几个分步表单组成，以实现所需的功能。例如，某些域对象以类似于向导的方式拆分为一组表单视图（我的视图模型）。输入的值是否为 int、给定的电子邮件是否有效等方面的验证发生在视图模型上。
我计划重新使用 viewmodel 类来表示 api 中的用户输入。
例如WebUI：public ActionResult Save(FormOne form){...} API： public ActionResult Save(String apiKey, FormOne form){...}
但这非常困难，即在 WebUI 视图模型和 API 视图模型之间建立完美的映射。
在这种情况下，什么才是好的设计？
a) 为 API 创建一个新的视图模型？ b) 尽可能使用现有的视图模型 - 在适当的情况下创建新类 c) 还有什么吗？
谢谢， 是
I recently came across a requirement in creating an API for an existing web portal. The current web UI will remain as it is and the API will provide the extra functionality for any clients that would like to build apps on top of the core app.
The web ui is pretty complex and consists of several step-by-step forms to achieve the desired functionality. For instance, some domain object is split into a set of form views (my viewmodel) in a wizard-like fashion. The validation in terms of whether the value entered is an int, whether the email given is valid etc happens on the viewmodel.
I was planning to re-use the viewmodel classes to represent the user input in the api.
e.g. WebUI: public ActionResult Save(FormOne form){...}
API: public ActionResult Save(String apiKey, FormOne form){...}
But this is so difficult i.e. have a perfect mapping between the WebUI viewmodel and the API viewmodel.
What constitutes a good design in this case?
a) Create a new viewmodel for the API?
b) Use the existing viewmodel when possible - create new classes where appropriate
c) Something else?
Thanks,
Y
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一个 ViewModel 只能被一个 View 使用。
不要重复使用它们，这只是问题的根源。
有时，我们想要违反DRY以减少耦合。这是其中之一。
创建新的 ViewModel 来为您的 API 提供服务。
A ViewModel should only be used by one View.
Don't reuse them, it is only a source of problems.
Sometimes, we want to violate DRY in order to reduce coupling. This is one of those times.
Make new ViewModels to serve your API.