Entitas dan layanan sebagai dasar logika terdistribusi untuk pola desain MVC

Saat mengembangkan aplikasi dari skala yang berbeda, menjadi semakin menarik untuk menerapkan pendekatan yang berbeda untuk merancang aplikasi web. Baru-baru ini, masalah pemisahan logika dalam proyek besar berdasarkan pola desain MVC menjadi sangat akut.

Entitas dan layanan

Entitas

Karena tugas menjadi lebih kompleks dan kompleks, dan tidak mungkin untuk menyimpan semua data dalam database, diputuskan untuk membuat entitas data statis dalam proyek tersebut. Intinya sederhana - data statis dasar disimpan di tempat tertentu, yang dapat dioperasikan dalam kode PHP, dan representasi bahasa Inggrisnya dimasukkan ke dalam database.



Dalam tampilan dasar, kelas Entity.php mungkin terlihat seperti ini:

declare(strict_types = 1);

namespace entities;

class Entity {
	protected static $map;
	
	public static function getMap():array {
		return static::$map;
	}
}

Pewarisnya harus mengimplementasikan properti $ map, yang akan mereka terima sebagai berikut:

E1::getMap();

Selain itu, sebagian besar data statis akan memenuhi logika penerimaan. Jika Anda perlu mengelompokkan data atau memilih data tambahan, logika ini sudah diterapkan di kelas yang diwariskan.

Jasa

Layanan dirancang untuk menyimpan logika bisnis aplikasi. Selain itu, layanan dapat digunakan sebagai logika yang terpisah dari kerangka kerja. Layanan adalah kumpulan metode yang mengimplementasikan logika aplikasi. Ketentuan yang ditentukan untuk layanan:

• layanan tidak boleh secara independen mengakses pengontrol dan tampilan;
• layanan dapat mengakses database, model dan entitas.

Dalam kasus terbaik, pengontrol harus mengirimkan semua data yang diperlukan ke layanan, tetapi situasi mungkin muncul yang perlu merujuk ke beberapa model secara independen untuk mendapatkan data. Tidak ada yang salah dengan itu, tetapi lebih baik mengikuti logika bahwa pengontrol mengoperasikan rute data.



Secara default, layanan tidak mengimplementasikan logika standar apa pun, karena ini adalah eksekusi unik dari bagian proyek. Oleh karena itu, diputuskan bahwa tidak ada kelas layanan dasar yang akan dibuat. Perlu dicatat, bahwa lebih baik membuat kelas dasar meskipun kosong. Hal ini disebabkan oleh fakta bahwa suatu saat mungkin akan datang ketika semua ahli waris harus memiliki logika yang sama atau menjalankan beberapa metode. Agar tidak membuat perubahan di area warisan di semua kelas, lebih mudah untuk mewarisi dari kelas dasar, di mana situasi ini jauh lebih mudah dan lebih murah di area sumber daya sementara.



Secara umum, aliran data dalam arsitektur yang diusulkan dapat direpresentasikan sebagai berikut:

1. Data atau permintaan masuk ke pengontrol.
2. Pengontrol berkomunikasi dengan model, layanan, dan entitas secara dua arah. Di sini dia menerima dan mengembalikan beberapa data.
3. Layanan mengirimkan data ke pengontrol, menerima atau mengirim data ke model.
4. Pengontrol mengirimkan data yang diterima ke tampilan.

Dengan demikian, ternyata data dan prinsip aplikasi didistribusikan antara elemen MVC dasar dan elemen baru.

Kesimpulan

Perlu dicatat bahwa pengenalan pendekatan ini memungkinkan untuk secara signifikan menyederhanakan pengembangan aplikasi dan mengontrol aliran data. Sebagian besar data diambil dari database, yang mengurangi ukurannya dan meningkatkan kecepatan aplikasi secara keseluruhan dengan mengurangi jumlah permintaan.