James - to clarify, the duplication I was referring to is having both Forms and Serializers do validation. I often work with web apps where data for the same model can arrive via user input, serializer, or created in some backend process e.g. Celery. If forms/serializers are your validation layer, you need to duplicate it and worry about how to keep them from diverging over time as there's no single source of truth. I also don't relish the thought of needing to use a Form or Serializer every time I alter a Model's data.
Perhaps we think about validation differently. I consider it to be critical to maintain complex systems with any kind of confidence, any time data is being created or changed, regardless of where that change comes from. Bugs can happen anywhere and validation is the best (only?) option to prevent data-related bugs. On Thursday, October 6, 2022 at 12:03:28 PM UTC-7 James Bennett wrote: > On Thu, Oct 6, 2022 at 9:00 AM Aaron Smith <aa...@aaronsmith.co> wrote: > >> James - The problem with moving validation up the stack, i.e. to logical >> branches from Model (Form, Serializer) is that you must duplicate >> validation logic if your data comes from multiple sources or domains (web >> forms *and* API endpoints *and* CSVs polled from S3. Duplication leads >> to divergence leads to horrible data integrity bugs and no amount of test >> coverage can guarantee safety. Even if you consider Django to be "only a >> web framework" I would still argue that validation should be centralized in >> the data storage layer. Validity is a core property of data. Serialization >> and conversion changes between sources and is a different concern than >> validation. >> > > I would flip this around and point out that the duplication comes from > seeing the existing data conversion/validation layer and deciding not to > use it. > > There's nothing that requires you to pass in an HttpRequest instance to > use a form or a serializer -- you can throw a dict of data from any source > into one and have it convert/validate for you. Those APIs are also > designed to be easy to check and easy to return useful error messages from > on failed validation, while a model's save() has no option other than to > throw an exception at you and demand you parse the details out of it > (because it was designed as part of an overall web framework that already > had the validation layer elsewhere). > > So I would argue, once again, that the solution to your problem is to use > the existing data conversion/validation utilities (forms or serializers) > regardless of the source of the data. If you refuse to, I don't think > that's Django's problem to solve. > >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/458d7bbd-b542-4e9a-ab62-91afdfe4b78fn%40googlegroups.com.
