Model binding adalah proses otomatis ASP.NET Core mengambil data dari request (baik dari route, query string, header, maupun body) dan mengubahnya menjadi object C# yang bisa langsung dipakai di dalam action method, menghilangkan kebutuhan parsing manual data request satu per satu.

Validation bekerja berdampingan dengan model binding, memastikan data yang masuk memenuhi aturan tertentu sebelum diproses lebih lanjut, baik melalui data annotation yang ditulis langsung di model, maupun validasi custom yang lebih kompleks untuk aturan bisnis spesifik.

Artikel ini membahas cara kerja model binding untuk berbagai sumber data, penerapan data annotation untuk validasi dasar, serta cara memeriksa dan merespons hasil validasi yang gagal dengan pesan error yang informatif bagi konsumen API.

Model Binding Otomatis ke Object Kompleks

Model binding mengubah JSON body menjadi object C# otomatis

public class ProdukDto { public string Nama { get; set; } public decimal Harga { get; set; } } [HttpPost] public IActionResult Tambah(ProdukDto produk) { return Ok(produk); } // Body JSON { "nama": "Laptop", "harga": 8000000 } // otomatis terisi ke property Nama dan Harga
ASP.NET Core secara otomatis mencocokkan nama field pada JSON body (tidak case-sensitive) dengan nama property pada class C#, mengonversi tipe data sesuai kebutuhan, dan mengisi object ProdukDto tanpa perlu kode parsing manual sama sekali dari developer.

Data Annotation untuk Validasi Dasar

Data annotation mendefinisikan aturan validasi langsung pada property

public class ProdukDto { [Required(ErrorMessage = "Nama produk wajib diisi")] [StringLength(100, MinimumLength = 3)] public string Nama { get; set; } [Range(1000, 100000000, ErrorMessage = "Harga harus antara 1.000 - 100.000.000")] public decimal Harga { get; set; } }
Data annotation seperti [Required], [StringLength], dan [Range] mendefinisikan aturan validasi langsung di atas property model, dan ketika dikombinasikan dengan atribut [ApiController] pada controller, ASP.NET Core akan otomatis memvalidasi model tersebut sebelum action method dijalankan, mengembalikan response 400 Bad Request secara otomatis jika validasi gagal.

Memeriksa ModelState Secara Manual

ModelState.IsValid memeriksa hasil validasi data annotation

[HttpPost] public IActionResult Tambah(ProdukDto produk) { if (!ModelState.IsValid) { return BadRequest(ModelState); } // lanjutkan proses jika valid return Ok(produk); }
Meski [ApiController] sudah menangani validasi otomatis untuk kebanyakan kasus, memeriksa ModelState.IsValid secara manual tetap berguna ketika ingin menambahkan logika kustom sebelum mengembalikan error, atau ketika atribut [ApiController] tidak dipakai, misalnya pada controller MVC biasa yang menangani form HTML.

Validasi Custom dengan IValidatableObject

IValidatableObject untuk validasi yang melibatkan beberapa property

public class PemesananDto : IValidatableObject { public DateTime TanggalMulai { get; set; } public DateTime TanggalSelesai { get; set; } public IEnumerable<ValidationResult> Validate(ValidationContext context) { if (TanggalSelesai < TanggalMulai) yield return new ValidationResult("Tanggal selesai harus setelah tanggal mulai"); } }
Untuk aturan validasi yang melibatkan hubungan antar beberapa property, seperti memastikan tanggal selesai selalu setelah tanggal mulai, data annotation sederhana tidak cukup. IValidatableObject memungkinkan logika validasi custom yang lebih kompleks ditulis langsung di dalam model, tetap terintegrasi dengan mekanisme ModelState yang sama.

Custom Validation Attribute untuk Aturan Bisnis Spesifik

Membuat ValidationAttribute kustom untuk aturan yang tidak tersedia bawaan

public class MinimumAgeAttribute : ValidationAttribute { private readonly int _minAge; public MinimumAgeAttribute(int minAge) { _minAge = minAge; } protected override ValidationResult? IsValid(object? value, ValidationContext context) { if (value is DateTime birthDate) { var age = DateTime.Today.Year - birthDate.Year; if (birthDate.Date > DateTime.Today.AddYears(-age)) age--; if (age < _minAge) return new ValidationResult($"Usia minimal {_minAge} tahun."); } return ValidationResult.Success; } } public class RegisterDto { [Required] [MinimumAge(17)] public DateTime TanggalLahir { get; set; } } // Body { "tanggalLahir": "2015-01-01" } -> 400 BadRequest, pesan "Usia minimal 17 tahun."

Data annotation bawaan seperti [Required], [StringLength], dan [Range] cukup untuk validasi format sederhana, tetapi banyak aturan bisnis nyata membutuhkan logika yang lebih spesifik, misalnya validasi usia minimal, format nomor telepon sesuai operator tertentu, atau kombinasi dua field yang saling bergantung. Untuk kasus seperti ini, ASP.NET Core memungkinkan pembuatan custom validation attribute dengan mewarisi kelas ValidationAttribute dan meng-override method IsValid.

Keunggulan menaruh aturan di dalam custom attribute dibandingkan menulis if-else manual di action method adalah reusability dan konsistensi pesan error. Attribute seperti [MinimumAge(17)] bisa dipasang ulang pada DTO lain tanpa duplikasi kode, dan karena ModelState divalidasi otomatis sebelum action method dieksekusi (berkat [ApiController]), response 400 BadRequest beserta pesan error sudah terbentuk tanpa perlu menulis pengecekan tambahan di dalam controller.

Untuk validasi yang melibatkan lebih dari satu properti sekaligus, seperti memastikan tanggal selesai tidak boleh lebih awal dari tanggal mulai, pendekatan yang lebih tepat adalah mengimplementasikan interface IValidatableObject pada DTO tersebut, karena ValidationAttribute standar hanya menerima nilai satu properti tunggal dan tidak memiliki akses langsung ke properti lain dalam objek yang sama.

FluentValidation sebagai Alternatif Data Annotation

FluentValidation memisahkan seluruh aturan validasi ke class tersendiri

public class RegisterDto { public string Email { get; set; } = string.Empty; public string Password { get; set; } = string.Empty; public int Usia { get; set; } } public class RegisterDtoValidator : AbstractValidator<RegisterDto> { public RegisterDtoValidator() { RuleFor(x => x.Email).NotEmpty().EmailAddress(); RuleFor(x => x.Password).MinimumLength(8) .WithMessage("Password minimal 8 karakter."); RuleFor(x => x.Usia).InclusiveBetween(17, 100); } } // Program.cs builder.Services.AddValidatorsFromAssemblyContaining<RegisterDtoValidator>(); builder.Services.AddFluentValidationAutoValidation(); // Body { "email": "salah", "password": "123", "usia": 10 } -> 400 BadRequest // dengan tiga pesan error sekaligus, tanpa satu baris kode validasi di controller

Data annotation seperti [Required] dan [EmailAddress] cukup praktis untuk aturan sederhana, tetapi menumpuk banyak atribut pada satu DTO membuat class tersebut bercampur antara definisi struktur data dan logika validasi. FluentValidation menawarkan pendekatan berbeda dengan memisahkan seluruh aturan validasi ke dalam class validator tersendiri yang mewarisi AbstractValidator, sehingga DTO tetap bersih sebagai model data murni. Pemisahan ini juga memudahkan penggunaan ulang aturan validasi yang sama pada beberapa DTO berbeda lewat composable validator.

Sintaks fluent seperti RuleFor(x => x.Password).MinimumLength(8) lebih ekspresif untuk aturan kompleks dibanding merangkai banyak atribut data annotation, terutama ketika sebuah properti membutuhkan beberapa kondisi sekaligus atau validasi yang bergantung pada properti lain lewat method When() atau DependentRules(). Pendekatan ini juga lebih mudah diuji secara terpisah karena validator bisa diinstansiasi langsung di unit test tanpa perlu menjalankan seluruh pipeline HTTP. Pesan error pun bisa disesuaikan per aturan lewat WithMessage, termasuk mendukung penempatan placeholder dinamis seperti nilai minimum yang dilanggar.

Setelah AddFluentValidationAutoValidation() didaftarkan, validator akan otomatis dijalankan sebelum action method dieksekusi, persis seperti mekanisme ModelState bawaan pada data annotation, sehingga migrasi dari data annotation ke FluentValidation tidak mengubah cara controller menerima request yang sudah tervalidasi. Tim yang mengelola banyak DTO dengan aturan validasi rumit umumnya lebih memilih FluentValidation karena skalabilitasnya lebih baik dibanding menumpuk atribut pada class yang sama. Validator juga bisa menerima dependency lewat constructor, misalnya untuk memeriksa keunikan email langsung ke database saat validasi dijalankan.

IValidatableObject untuk Validasi yang Melibatkan Lebih dari Satu Field

public class PeminjamanRequest : IValidatableObject { public DateTime TanggalMulai { get; set; } public DateTime TanggalSelesai { get; set; } public IEnumerable<ValidationResult> Validate(ValidationContext context) { if (TanggalSelesai <= TanggalMulai) yield return new ValidationResult( "Tanggal selesai harus setelah tanggal mulai", new[] { nameof(TanggalSelesai) }); } } // ModelState.IsValid otomatis false jika aturan ini dilanggar

Data annotation seperti Required atau Range bekerja per properti secara independen dan tidak bisa membandingkan nilai dari dua field sekaligus dalam satu aturan. IValidatableObject memberi tempat khusus untuk aturan yang bergantung pada kombinasi beberapa nilai, misalnya memastikan tanggal selesai tidak lebih awal dari tanggal mulai, tanpa perlu menulis validator eksternal terpisah untuk kasus yang masih tergolong sederhana dan hanya melibatkan satu model saja.

Karena interface ini dipanggil otomatis oleh framework setelah proses model binding selesai, hasil validasinya langsung masuk ke ModelState yang sama dengan validasi attribute biasa, sehingga action tidak perlu membedakan dari mana sumber error tersebut berasal. Untuk aturan bisnis yang jauh lebih kompleks dan melibatkan pengecekan ke database, pendekatan FluentValidation biasanya lebih mudah dirawat dibanding menumpuk banyak logika pengecekan langsung di dalam class model.

Kesalahan Umum yang Sering Terjadi

Mengandalkan Validasi Client-Side Saja

Validasi yang hanya dilakukan di sisi client (misalnya JavaScript) bisa dilewati dengan mudah oleh pengguna yang mengirim request langsung ke API, sehingga validasi di sisi server melalui data annotation tetap wajib ada sebagai lapisan pertahanan utama.

Tidak Memeriksa ModelState Sebelum Memproses Data

Pada controller yang tidak ditandai [ApiController] (seperti controller MVC biasa), lupa memeriksa ModelState.IsValid secara manual bisa menyebabkan data yang sebenarnya tidak valid tetap diproses lebih lanjut.

Menaruh Logika Bisnis Kompleks di Dalam Data Annotation

Data annotation sebaiknya hanya dipakai untuk validasi format sederhana; logika bisnis yang kompleks dan melibatkan pengecekan ke database sebaiknya ditangani di layer service, bukan dipaksakan ke dalam atribut validasi model.

Kapan Pendekatan Ini Tidak Cocok Dipakai

Data annotation memberikan validasi yang cepat dan deklaratif langsung pada model, sangat cocok untuk aturan sederhana seperti field wajib diisi atau rentang nilai tertentu, dengan sedikit kode yang perlu ditulis.

Untuk validasi yang lebih kompleks dan melibatkan aturan bisnis yang mungkin berubah seiring waktu, library validasi eksternal seperti FluentValidation menawarkan pemisahan logika validasi dari model itu sendiri, yang bisa lebih mudah diuji dan dipelihara dibanding menumpuk banyak data annotation pada satu class.

Ringkasan

Model binding menghilangkan kebutuhan parsing data request secara manual, sementara validation memastikan data yang masuk memenuhi aturan yang ditentukan sebelum diproses lebih lanjut. Kombinasikan data annotation untuk validasi sederhana dengan IValidatableObject atau library eksternal untuk aturan yang lebih kompleks sesuai kebutuhan aplikasi.

Seri Belajar .NET Core:

← Sebelumnya: Routing dan Controller di ASP.NET Core

→ Selanjutnya: Dependency Injection di ASP.NET Core (segera terbit)