ozzo-validation: an idiomatic Go validation package

<p>Most existing Go validation packages rely on struct tags to specify validation rules associated with struct fields. While this approach is handy for specifying simple rules, it is error prone and can quickly become unmanageable for complicate rules that often need to be parameterized.</p> <p>ozzo-validation takes a different approach. It lets you to specify validation rules in usual program constructs so that coding mistakes can be early detected by IDEs or compilers. Out-of-box it provides dozens of validators which can be easily customized and extended. It supports validating structs, arrays/slices, or scalar values. It also provides special support for database/sql data types.</p> <p>Below is the repo link. Your comments are very welcome!</p> <p><a href="https://github.com/go-ozzo/ozzo-validation">https://github.com/go-ozzo/ozzo-validation</a></p> <hr/>**评论：**<br/><br/>mwholt: <pre><p>Nice. Validation logic does not belong in struct tags, so +1 on writing this package.</p></pre>schumacherfm: <pre><p>+1 but it still uses too much reflection. The API should be something like the logger of uber-go/zap, just type safe.</p></pre>proud_to_be_proud: <pre><p>I completely agree and blame developers who want to look &#34;clever&#34; and &#34;show off&#34; for this absolute travesty. Overcomplicating things and using the wrong tools for the job are never cool.</p></pre>LadyDascalie: <pre><p>This is great! I agree 100% with the premise that you should&#39;t be doing this in struct tags, this is much more sane, definitely going to give it a shot on a project I&#39;m building currently!</p></pre>mustafaakin: <pre><p>Its really nice, while struct based ones were useful enough, they were easily becoming hard to main as you said.</p></pre>chrj: <pre><p>Very cool!</p></pre>daveddev: <pre><p>Dynamic field names and self-referential methods feel dirty to me.</p></pre>qiangxue: <pre><p>Thanks for your feedback! Totally agree with you about the dynamic field name issue which was already reported. nsf gave a clever solution which I&#39;m going to implement.</p> <p>Could you elaborate a bit more about self-referential method issue?</p></pre>daveddev: <pre><p>Instead of:</p> <pre><code>return valid.Validate(&amp;a). Mandatory(&amp;a.FirstName, valid.MaxLength(250)). Mandatory(&amp;a.LastName, valid.MaxLength(250)). Mandatory(&amp;a.Email, valid.Email). Optional(&amp;a.Age, valid.PositiveInteger). Done() </code></pre> <p>Rules could be in a separate library and, using a named import (&#34;vr&#34; for validation rule), the code would be:</p> <pre><code>return validation.Validate( vr.Mandatory(&amp;a.FirstName, vr.MaxLength(250), vr.Mandatory(&amp;a.LastName, vr.MaxLength(250), vr.Mandatory(&amp;a.Email, vr.Email), vr.Optional(&amp;a.Age, vr.PositiveInteger), ) </code></pre> <p>This would be a more functional approach. Also, I&#39;m not certain that the first arg &#34;&amp;a&#34; is necessary, so I left it out. <a href="https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis" rel="nofollow">https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis</a></p> <p>Edit to add: I had planned to implement this exact thing by forking someone&#39;s (not yet sure whose) validation rules and forming the API to my liking. So, if you make this happen, I&#39;d use it immediately.</p></pre>FourSigma: <pre><p>Check out --- <a href="https://github.com/FourSigma/validate" rel="nofollow">https://github.com/FourSigma/validate</a> Let me know what you think. Uses the functional optional pattern. Still in beta.</p></pre>