Bagaimana untuk Merekabentuk DTO Permintaan Cekap dan Konsisten dalam ServiceStack?

ServiceStack Request DTO Design

Dalam RESTful API, adalah perkara biasa untuk mempunyai berbilang perkhidmatan untuk tujuan yang berbeza. Walaupun tergoda untuk mencipta perkhidmatan berasingan untuk setiap permintaan unik, ia boleh membawa kepada pertindihan yang tidak perlu dan seni bina yang membengkak. ServiceStack mempromosikan pendekatan yang berbeza, menggalakkan pengumpulan perkhidmatan berdasarkan semantik panggilan dan jenis respons mereka.

Membezakan Operasi Perkhidmatan vs Jenis

Operasi perkhidmatan (Permintaan DTO) harus menangkap tindakan unik sesuatu perkhidmatan, manakala jenis DTO yang mereka kembalikan mewakili entiti atau bekas data. DTO Permintaan hendaklah menggunakan kata kerja (cth., "Dapatkan", "Cari") untuk menyampaikan tindakan mereka, manakala jenis DTO hendaklah menggunakan kata nama (cth., "Pelanggan", "Produk") untuk mewakili entiti mereka.

Mengembalikan Respons Generik

Dalam kes permintaan GET biasa, ServiceStack tidak memerlukan sifat ResponseStatus sebagai tindak balas DTO. Sebaliknya, DTO ErrorResponse generik akan dilemparkan dan bersiri pada klien jika ralat berlaku. Ini menghapuskan keperluan untuk sifat ResponseStatus yang eksplisit dalam respons anda.

Tama Konsisten

Untuk meningkatkan kebolehbacaan dan perihalan diri, adalah disyorkan untuk menggunakan tatanama yang konsisten dalam kontrak perkhidmatan anda. Simpan kata kerja "Dapatkan" untuk perkhidmatan yang mendapatkan semula hasil tunggal berdasarkan pengecam unik. Untuk perkhidmatan carian yang mengembalikan berbilang hasil, gunakan awalan "Cari" atau "Cari". Selain itu, berikan nama hartanah yang jelas dan deskriptif yang menunjukkan tujuannya dalam DTO permintaan.

Perkhidmatan Had Tempahan Difaktorkan Semula

Berdasarkan prinsip ini, perkhidmatan Had Tempahan yang difaktorkan semula berikut dicadangkan:

[Route("/bookinglimits/{Id}")]
public class GetBookingLimit : IReturn<BookingLimit>
{
    public int Id { get; set; }
}

public class BookingLimit
{
    public int Id { get; set; }
    public int ShiftId { get; set; }
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
    public int Limit { get; set; }
}

[Route("/bookinglimits/search")]
public class FindBookingLimits : IReturn<List<BookingLimit>>
{
    public DateTime BookedAfter { get; set; }
}

Pelaksanaan Perkhidmatan

Pelaksanaan perkhidmatan boleh dipermudahkan dengan menggunakan atribut [Authenticate] sekali pada kelas perkhidmatan dan bukannya setiap DTO permintaan. Kod berikut menunjukkan pelaksanaan ini:

[Authenticate]
public class BookingLimitService : AppServiceBase
{ 
    public BookingLimit Get(GetBookingLimit request) { ... }

    public List<BookingLimit> Get(FindBookingLimits request) { ... }
}

Pengendalian dan Pengesahan Ralat

Pengendalian dan pengesahan ralat boleh disesuaikan menggunakan keupayaan Pengesahan Fasih terbina dalam ServiceStack. Daripada menyuntik pengesah ke dalam perkhidmatan, anda boleh mendaftarkannya dalam AppHost dengan baris berikut:

container.RegisterValidators(typeof(CreateBookingValidator).Assembly);

Untuk operasi dengan kesan sampingan (cth., POST/PUT), anda boleh mentakrifkan pengesah seperti berikut :

public class CreateBookingValidator : AbstractValidator<CreateBooking>
{
    public CreateBookingValidator()
    {
        RuleFor(r => r.StartDate).NotEmpty();
        RuleFor(r => r.ShiftId).GreaterThan(0);
        RuleFor(r => r.Limit).GreaterThan(0);
    }
}

Atas ialah kandungan terperinci Bagaimana untuk Merekabentuk DTO Permintaan Cekap dan Konsisten dalam ServiceStack?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!