Questions tagged «validation»

验证函数输入参数的最佳位置在哪里：在调用方中还是在函数本身中？ 因为我想改善自己的编码风格，所以我尝试找到此问题的最佳实践或一些规则。何时何地更好。 在我以前的项目中，我们曾经检查并处理函数中的每个输入参数（例如，如果它不为null）。现在，我在这里已经在一些答案以及《实用程序员》一书中读到，输入参数的验证是调用者的责任。 因此，这意味着我应该在调用函数之前验证输入参数。调用该函数的任何地方。这就提出了一个问题：不是在调用函数的所有地方都产生了检查条件的重复吗？ 我对空条件不感兴趣，但对任何输入变量的验证（sqrt函数的负值，被零除，状态和邮政编码的错误组合或其他任何东西）都不感兴趣。 有一些规则如何决定在哪里检查输入条件？ 我在考虑一些争论： 当无效变量的处理方式可能有所不同时，最好在调用方进行验证（例如，sqrt()函数-在某些情况下，我可能想使用复数，因此我在调用方中处理条件） 当每个调用者的检查条件都相同时，最好在函数内部进行检查，以避免重复 调用方中输入参数的验证仅在使用此参数调用许多函数之前进行。因此，在每个函数中验证参数无效 正确的解决方案取决于具体情况 我希望这个问题不能与其他任何问题重复，我搜索了这个问题，发现了类似的问题，但是他们没有确切提及此案。

16 coding-standards  validation  dry 

当我有大量需要验证的数据时，我应该仅出于验证目的创建一个新类，还是应该坚持方法内验证？ 我的特定示例设想了一个锦标赛和一个事件/类别类：Tournament和Event，它模拟了一个体育锦标赛，每个锦标赛都有一个或多个类别。 这些类别中有很多事情需要验证：球员应该为空，应该是唯一的，每个球员应该参加的比赛数量，每次比赛都有的球员数量，预定义的对决，以及包括许多其他东西在内的非常重要的事情。复杂的规则。 我还需要整体验证某些部分，例如类如何相互集成。例如，对a Player进行单一验证就可以了，但是如果一个事件两次具有相同的玩家，那就是验证错误。 那怎么办呢：：使用模型类的设置器和类似方法添加数据时，我完全忘记了任何预检查，而是让验证类来处理。 因此，我们将有类似EventValidator与Event作为成员，和validate()用来验证整个对象的方法，再加上单一的方法来验证所有成员的规则。 然后，在实例化有效对象之前，我将执行验证以防止出现非法值。 我的设计正确吗？我应该做些不同的事情吗？ 另外，我应该使用布尔值返回验证方法吗？或者，如果验证失败，则抛出异常？在我看来，最好的选择是布尔返回方法，并在实例化对象时引发异常，例如： public Event() { EventValidator eventValidator = new EventValidator(this); if (!eventValidator.validate()) { // show error messages with methods defined in the validator throw new Exception(); // what type of exception would be best? should I create custom ones? } }

16 java  design  data  validation 

除了（ActiveRecord）模型外，我还始终在数据库级别应用约束。但是我一直在想这是否真的必要吗？ 一点背景 最近，我不得不对模型的基本自动时间戳生成方法进行单元测试。通常，测试会创建模型的实例并保存而不进行验证。但是表定义中还有其他必填字段不能为空，这意味着即使我跳过ActiveRecord验证，也无法保存实例。因此，我在考虑是否应该从数据库本身中删除此类约束，并让ORM处理它们？ 如果我跳过db，imo中的约束，可能的优点 - 可以修改模型中的验证规则，而不必迁移数据库。 可以跳过测试中的验证。 可能的缺点？ 如果可能ORM验证失败或被旁路，则数据库不会检查约束。 你怎么看？ 编辑在这种情况下，我使用的是Yii Framework，它从数据库生成模型，因此也生成了数据库规则（尽管我总是可以自己在生成后编写它们）。

13 database  orm  validation  dry 

我知道您在思考（或大喊大叫），“不是另一个问题，它要求验证在分层体系结构中属于什么？！？” 好吧，是的，但是希望这会在这个问题上有所不同。 我坚信验证的形式多种多样，是基于上下文的，并且在体系结构的每个级别都有所不同。这是后期的基础-有助于确定应在每个层中执行哪种类型的验证。另外，经常出现的一个问题是授权检查在哪里。 示例场景来自餐饮业务的应用程序。白天，司机可能会不定期地将卡车上载到现场的任何多余现金上交办公室。该应用程序允许用户通过收集驾驶员的ID和金额来记录“现金下降”。这是一些基本代码来说明涉及的层： public class CashDropApi // This is in the Service Facade Layer { [WebInvoke(Method = "POST")] public void AddCashDrop(NewCashDropContract contract) { // 1 Service.AddCashDrop(contract.Amount, contract.DriverId); } } public class CashDropService // This is the Application Service in the Domain Layer { public void AddCashDrop(Decimal amount, Int32 driverId) …

13 domain-driven-design  validation  layers 

我正在研究干净的软件，因此，我极大地重新思考了如何设计和编写软件的大量方法。 不过，我仍在努力处理业务规则，例如“保存某些项目的更新，首先加载我有权查看/编辑的所有项目列表，确认该项目在列表中，并且该商品类别当前未被锁定（以及其他规则等）。”，因为这是（复杂但非典型的）业务规则，因此应在应用程序域中进行处理，而不是将业务逻辑推送到db / persistence层。 但是在我看来，为了有效地检查这些条件，通常最好使用精心设计的数据库查询来最好地处理它，而不是将所有数据加载到应用程序域中... 如果不进行过早的优化，有什么推荐的方法或鲍勃叔叔的文章处理这个问题？还是他会说“在域中进行验证，直到出现问题”？ 除了最基本的用例之外，我真的在努力寻找任何好的示例/样本。 更新： 大家好，谢谢您的答复。我应该更清楚一些，我已经写了很长时间（主要是Web应用程序）软件，并且肯定已经经历并同意您共同描述的所有主题（通过后端验证，一般不信任客户端数据仅在需要时才追求原始效率，但是在可用时承认db工具的优势，等等），并且已经经历了开发人员学习生命周期的“全部整合”以“构建具有N层应用程序的大型胖控制器”代码趋势，现在真的很喜欢研究干净/单一责任的样式等，这主要是由于最近有一些项目随着项目的发展以及对客户的进一步要求逐渐演变为笨拙且分布广泛的业务规则。 特别是，我在构建REST的API面向客户和内部使用功能的背景下，看着清新的风格建筑，其中许多业务规则可能是多比基本上你在网上看到每一个例子更复杂（甚至由Clean / Hex体系结构专家自己完成）。 所以我想我真的是在问（并且没有清楚地说出）Clean和REST api会如何放置在一起，这些天您看到的大多数MVC东西都带有传入的请求验证器（例如.NET中的FluentValidation库），但是其中许多我的“验证”规则不是“这是少于50个字符的字符串”，而是更多的，“如果某个相关对象当前已被Team X锁定，则该调用此用户案例/交互者的用户可以对数据集执行此操作吗？直到本月下旬，等等”。。。那些涉及深层次的验证，其中适用于业务域对象和域规则的数量。 我是否应该将这些规则分解为特定类型的Validator-object类型，以与每个用例交互器一起使用（受FluentValidator项目的启发，但涉及更多的业务逻辑和数据访问），我是否应该将验证视为类似于Gateway，我应该将那些验证放入网关（我认为这是错误的）等。 作为参考，我会去像几篇文章这样，但马蒂亚不讨论验证了。 但是我想我的问题的简短答案很像我接受的答案：“这绝非易事，要视情况而定”。

13 clean-code  domain-model  validation  business-rules 

以防万一代码的另一部分没有正确编码，是实现无用异常处理的好习惯吗？ 基本例子 一个简单的，所以我不会让每个人都放松:)。 假设我正在编写一个应用程序，它将显示一个人的信息（姓名，地址等），数据是从数据库中提取的。假设我是UI部分的编码人员，而其他人正在编写DB查询代码。 现在，假设您的应用程序规范说明如果该人员的信息不完整（例如，数据库中缺少该名称），则对查询进行编码的人员应通过为缺失字段返回“ NA”来处理此问题。 如果查询的编码不正确怎么办？如果编写查询的人为您处理了不完整的结果，并且当您尝试显示信息时一切都崩溃了，因为您的代码不准备显示空的东西怎么办？ 这个例子很基础。我相信你们大多数人会说“这不是您的问题，您不应对这次崩溃负责”。但是，仍然是崩溃的一部分。 另一个例子 假设现在我是编写查询的人。规范与上面的说法不同，但是在向数据库中添加人员时，编写“插入”查询的人应确保所有字段均完整，以避免插入不完整的信息。我应该保护我的“选择”查询以确保为UI家伙提供完整的信息吗？ 问题 如果规范中没有明确指出“此人是负责处理这种情况的人”，该怎么办？如果第三方实现了另一个查询（类似于第一个查询，但在另一个DB上）并使用您的UI代码显示该查询，但在他的代码中不处理这种情况怎么办？ 即使我不是应该处理这种情况的人，我也应该采取必要的措施来防止可能的崩溃吗？ 我不是要寻找“他是崩溃的负责人”之类的答案，因为我不想在这里解决冲突，我想知道，如果我保护我的代码免受情况影响，这不是我的责任处理？在这里，一个简单的“如果空着做某事”就足够了。 通常，此问题解决了冗余异常处理。我之所以这样问，是因为当我一个人在一个项目上工作时，我可能会在连续的函数中编写2-3次类似异常处理的代码，以防万一我做错了什么，让一个糟糕的情况解决了。

12 language-agnostic  validation  exception-handling 

我喜欢MVC的可扩展性，它允许视图模型实现IValidatableObject，并添加自定义验证。 我尝试使我的控制器保持精简，使此代码成为唯一的验证逻辑： if (!ModelState.IsValid) return View(loginViewModel); 例如，登录视图模型实现IValidatableObject，通过构造函数注入获取ILoginValidator对象： public interface ILoginValidator { bool UserExists(string email); bool IsLoginValid(string userName, string password); } 似乎在视图模型中注入实例的Ninject并不是真正的惯例，甚至可能是反模式？ 这是一个好方法吗？有更好的吗？

12 architecture  asp.net-mvc  dependency-injection  validation  single-responsibility 

我考虑这个问题已有一段时间了，我很想征询其他开发人员的意见。 我倾向于具有非常防御性的编程风格。我典型的块或方法如下所示： T foo(par1, par2, par3, ...) { // Check that all parameters are correct, return undefined (null) // or throw exception if this is not the case. // Compute and (possibly) return result. } 另外，在计算过程中，我在取消引用所有指针之前先检查它们。我的想法是，如果存在某些错误，并且某些地方应该出现一些NULL指针，则我的程序应该很好地处理此问题，并且只是拒绝继续进行计算。当然，它可以通过日志或其他机制中的错误消息来通知问题。 换句话说，我的方法是 if all input is OK --> compute result else --> do not compute …

12 validation  user-interaction 

当我尝试为特定程序创建接口时，通常是在尝试避免引发依赖于未经验证的输入的异常。 因此，经常发生的事情是我想到了这样的一段代码（出于示例目的，这只是一个示例，不要介意它执行的功能，例如Java）： public static String padToEvenOriginal(int evenSize, String string) { if (evenSize % 2 == 1) { throw new IllegalArgumentException("evenSize argument is not even"); } if (string.length() >= evenSize) { return string; } StringBuilder sb = new StringBuilder(evenSize); sb.append(string); for (int i = string.length(); i < evenSize; i++) { sb.append(' …

11 design  design-patterns  programming-practices  performance  validation 

我们已经在一些代码上运行了Pex，并且一直在显示一些好东西（好东西，但是要在生产之前显示它们！）。 但是，Pex的优点之一是它不一定会停止尝试查找问题。 我们发现的一个方面是，在传递字符串时，我们没有检查空字符串。 所以我们改变了： if (inputString == null) 至 if (string.IsNullOrEmpty(inputString)) // *** 这解决了最初的问题。但是，当我们再次运行Pex时，它决定： inputString = "\0"; 造成了问题。然后 inputString = "\u0001"; 我们已经决定，如果遇到默认情况，可以使用默认值// ***，并且很高兴看到由任何其他奇数输入引起的异常（并对其进行处理）。 够了吗？

11 validation  strings  defensive-programming 

我想知道是否有人成功将Windows Workflow Foundation用于BusinessRules / Validation引擎，或者您是否知道一些示例代码或与此相关的文章。 如果您曾经使用过它，您怎么看？与其他BusinessRule / Validation系统相比如何？ 我在想类似的规则 if (A, B, and C) AllowAccess(); 要么 if (Value between X and Y) return true;

11 enterprise-architecture  validation  business-rules  workflow-foundation 

我正在使用允许管理员定义包含字段的表单的系统。然后，使用定义的表格将数据输入系统。有时，表单是由用户通过GUI填写的，有时，表单是根据另一个系统报告的值来填写的。 对于每个字段，管理员可以定义一个验证规则，以限制该字段的允许值。验证规则可以是“在字段中输入的值必须为True或False”到“在字段中输入的值必须存在于数据库表B的A列中”的任何内容。管理员可以随时更改字段的验证规则。 在这种情况下，您认为最适合验证每个字段正确填写的位置是什么？我目前有两种主要方法： 选项1：在域模型中验证 每个字段对象将包含管理员指定的验证规则。Field对象还将引用IValidator。尝试设置字段的值时，字段会将给定的值和验证规则传递给IValidator。如果给定的值无效，则将在另一个系统的GUI /接口中引发ValidationException并进行适当处理。 优点： 强大的保护功能，防止字段被意外分配违反验证规则的值 缺点： 数据访问层需要能够绕过验证并构造违反当前验证规则的字段。尽管管理员更改了字段的验证规则，但我们仍然需要能够基于旧数据构造Field对象，例如，当渲染多年前填充的表单时。每当我们存储字段时，都可以通过存储当前的验证规则来解决此问题。 在这种设计中，Field模型通过IValidator间接链接到数据访问层/存储库。服务/存储库的领域模型的注入似乎被普遍令人难以接受的。 选项2：在服务中验证 尝试确保所有尝试设置字段值的尝试都通过可确保验证规则成立的服务。如果违反了验证规则，则抛出ValidationException。 当然，当创建以前一直保存在数据库中的字段对象时，数据访问层将不会使用服务。 优点： 不违反“不要将服务/存储库注入您的域模型”的思想。 保留字段时，无需保留当前的验证规则。该服务可以简单地查询该字段的当前验证规则；查看历史记录数据时，字段的值不会更改。 缺点： 不能保证应该使用服务设置字段值的所有逻辑实际上都这样做。我认为这是一个主要缺点。似乎要做的就是有人写“ thisField.setValue（thatField.getValue（））”，并且可能会违反thisField的验证规则，而没有人明智。当数据访问层将要保留字段时，可以通过确保字段的值与验证规则匹配来缓解这种情况。 我目前更喜欢选项＃1，而不是选项＃2，主要是因为我将其视为业务逻辑，并认为选项2带来了将不良数据引入系统的更大风险。您更喜欢哪个选项，或者是否有比上述两个选项更适合这种情况的设计？ 编辑（验证的复杂性） 目前出现的验证案例相对简单。字段值必须是例如数字，日期，带时间的日期，或者是数据库列中的现有值。但是，我怀疑复杂性会随着时间逐渐增加。例如，验证解决方案的构建必须考虑国际化-诸如Date之类的内容可能会以特定于语言环境的语法输入。 我现在决定继续使用选项＃1，尝试注意不要为域模型分配太多职责。那些面临类似情况的人可能还想查看相关问题分层体系结构中的验证和授权以及数据输入验证-在哪里？多少？。

10 design-patterns  architecture  domain-driven-design  validation 

关于鸭子打字： 通过惯用性地不测试方法和函数体中的自变量类型，依靠文档，清晰的代码和测试来确保正确使用，可以帮助进行鸭子键入。 关于论证验证（EAFP：比宽恕更容易获得宽恕）。来自这里的改编示例： ...被认为是更pythonic的： def my_method(self, key): try: value = self.a_dict[member] except TypeError: # do something else 这意味着使用您的代码的其他任何人都不必使用真正的字典或子类-他们可以使用实现映射接口的任何对象。 不幸的是，实际上并不是那么简单。如果上述示例中的member可能是整数怎么办？整数是不可变的-因此将它们用作字典键是完全合理的。但是，它们也用于索引序列类型对象。如果member恰好是整数，则示例二可以让列表，字符串以及字典通过。 关于断言编程： 断言是检查程序内部状态是否符合程序员期望的一种系统方法，目的是捕获错误。特别是，它们非常适合捕获编写代码时做出的错误假设，或捕获其他程序员滥用接口的情况。此外，通过使程序员的假设显而易见，它们可以在一定程度上充当内联文档。（“显式优于隐式。”） 提到的概念有时会发生冲突，因此在选择是否完全不进行任何数据验证，进行强力验证或使用断言时，我会依靠以下因素： 强力验证。通过强力验证，我的意思是引发自定义Exception（ApiError例如）。如果我的函数/方法是公共API的一部分，则最好验证参数以显示有关意外类型的良好错误消息。通过检查类型，我并不是指仅使用isinstance，而是通过的对象是否支持所需的接口（鸭子输入）。当我记录API并指定期望的类型并且用户可能想以意外方式使用我的函数时，在检查这些假设时，我会感到更加安全。我通常使用isinstance，如果以后要支持其他类型或鸭子，则可以更改验证逻辑。 断言编程。如果我的代码是新的，我会使用很多断言。您对此有何建议？以后是否从代码中删除断言？ 如果我的函数/方法不是API的一部分，而是将其某些参数传递给我未编写，研究或测试的其他代码，则我会根据被调用的接口执行很多断言。我的逻辑背后-最好在我的代码中失败，然后在堆栈跟踪中加深10个级别，出现难以理解的错误，这迫使进行大量调试，然后无论如何都将断言添加到我的代码中。 断言，关于何时使用或不使用类型/值验证的评论和建议？很抱歉，问题不是最好的表述。 例如，考虑以下函数，其中Customer是SQLAlchemy声明性模型： def add_customer(self, customer): """Save new customer into the database. @param customer: Customer instance, whose id is None @return: merged into global session customer …

10 python  validation  assertions  duck-typing 

我有一个ASP.NET MVC应用程序，该应用程序使用查询服务来获取数据，并使用命令服务来发送命令。我的问题是关于命令部分的。 如果有请求进入，则命令服务将使用命令调度程序，该命令调度程序会将命令路由到其指定的命令处理程序。该命令处理程序首先验证命令，如果一切都可以接受，它将执行命令。 具体示例：AddCommentToArticleCommandHandler接收一个AddCommentToArticleCommand，该命令具有ArticleId，CommentText和EmailAddress。 第一; 必须进行验证，例如：-检查文章是否存在-检查文章是否未关闭-检查注释文本是否在20到500个字符之间，以及是否填写了电子邮件地址-检查电子邮件地址是否具有正确的格式。 我想知道将验证放在哪里？ 1 /在命令处理程序本身中。但是，它不能在其他命令处理程序中重用。 2 /在域实体中。但是，由于域实体不了解存储库或服务，因此它无法执行所需的验证（无法检查文章是否存在）。但是另一方面，如果实体不包含逻辑，则它将变成一个简单的数据容器，不遵循DDD原理。 3 /命令处理程序使用验证器，以便可以在其他命令处理程序中重用验证。 4 /其他机制？ 我正在寻找此特定示例的责任链，以及哪些对象（实体，存储库，...）在其中起作用。 从命令处理程序到存储库，您是否有实现此想法的想法？

10 c#  architecture  domain-driven-design  validation  cqrs 

在验证来自用户的输入（例如通过联系表）时，您是否同时使用客户端验证和服务器端验证技术？ 如果是这样，真的有必要吗？您在工程上吗？

10 web-development  validation