上周我在前端实现了日期验证，这是ASP.NET的结合，并且在很大程度上依赖于大量JavaScript代码，以避免服务器往返，直到实际保存表单。我觉得这个规则检查没有在服务器上完成，我感到很笨拙，但我们当前的架构和性能要求阻止了这一点。现在它不在我的手中。
理想情况下，这个检查应该在两个地方完成，但是然后服务器端检查将使用整洁，类型化，C＃完成，并且立即对开发该BO的开发人员可见，并且客户端检查实际上是通过甚至是副本，这是一个狡猾，但完全不同的代码。
在客户端实际复制服务器端检查有哪些方法？使用规则引擎，并且每边都有两个受信任的规则引擎应用相同的规则，实际上委托服务器检查由JavaScript完成，然后在渲染客户端中注册，这似乎是另一种选择，但似乎很有挑战性。
关于这个相当学术性和实际性问题的任何想法？
答案 0 :(得分：2)
ASP.NET的验证控件可以做到这一点。
ASP.NET验证控件还提供两种验证方式：服务器端或客户端。这些验证控件的优点在于，当它检测到浏览器能够执行时，它将执行客户端验证（除非已禁用客户端验证）。从而减少了往返。并且它将在必要时预先形成服务器端。这种客户端/服务器端检测和验证无需开发人员的额外工作即可完成！
http://www.devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=46
否则，您必须遵循相同的模型。创建设置规则，然后在两侧实现每个规则（如果可以，在控件中）。然后，允许开发人员选择要应用于哪个html控件的规则。
答案 1 :(得分：1)
好吧，您永远无法在客户端自动复制服务器端验证代码，因为
但是，将验证代码完全删除到服务器是完全可行的。当然，出于完全相同的两个原因，这是这种代码的最佳位置。使用Ajax技术和WebRequest对象，客户端中的一个简短验证存根可以很容易地调用服务器端验证函数，而不需要回发。
答案 2 :(得分：0)
我从未这样做过，但似乎您可以在服务器上的某个位置编写验证代码，然后让您的Web应用程序直接访问验证代码，同时每个客户端页面访问相同的Web服务公开代码使用AJAX。
在.NET世界中，这可以通过将验证代码编写为Web服务来完成。 AJAX客户端和服务器应用程序本身会调用此Web服务中的方法来进行验证（注意：从安全角度来看，这可能是个坏主意 - 我不知道）。
答案 3 :(得分：0)
我认为简单的规则引擎是您的最佳选择。根据您要执行的验证，它不需要太复杂。
其他任何事情都会涉及到服务器的额外往返（在C＃中执行所有验证）或让服务器执行JavaScript（我相信，这比实现规则引擎要困难得多）。
唯一的选择是复制代码（就像微软那样）。
答案 4 :(得分：0)
请参阅：MVC Validation - Keep it DRY with a service layer - What is best practice?
我能找到的最佳解决方案是在视图模型上推荐使用MVC的解决方案，它可以在客户端和服务器上进行一些验证。
答案 5 :(得分：0)
好的做法是系统条目应该进行验证以确保一致性。因此，在您的方案中，系统的条目是Web应用程序后端。所以你需要在那一侧进行验证。让我举个例子，假设我创建了一个自动化工具，将数据发布到您的Web应用程序，然后不涉及UI，但如果该工具不提供firstName，它将无法记录数据。
根据您的解释，您的Web应用程序似乎也包含服务层，但是当您的系统被划分为服务层和Web应用程序（作为哑UI）以收集用户输入时，这将更加明显。 / p>
现在你仍然需要（或者至少它也更好）为UI提供ui验证以及你提到的更好的用户体验。不应该使用UI验证来真正防止用户在数据一致性方面将字段留空，因为服务层不会（也不应该）允许用户。但它更适合用户体验（UX），因此用户可以获得更快的反馈。
有时，在逻辑上，UI和服务层上发生的检查类型是相似的。让我们说名字不应该是空的。然后可以以某种方式共享逻辑，但很多时候，您无法在客户端进行检查，因为您需要一些外部数据，资源，信息......进行验证。例如，可用库存项目的数量不能少于10.在这种情况下，您不能拥有该信息，或者如果可以，则无关紧要。因为您必须在保存部分上进行验证，这可能会在用户提交表单时更改。
因此，如果这是您拥有这两种类型验证的场景，那么最好使用服务端验证，并且在客户端也将信息（以异步方式）传递给服务并返回结果回来了。像this service side decision这样的东西。如果您在一个场景中混合使用这些验证，那么我甚至不会在仅限UI和服务验证上分配它们，因为我将进行整个验证服务。