12.08.2023
1127
İstənilən layihəni hazırlamağa başlamadan öncə proqramçıların ağlına gələn ilk sual: Layihəni MVC edək yoxsa API ilə front-endi ayıraq? olur.
Bu sual çox vaxt layihə menecerlərini narahat etsə də, bəzən full-stack developerlərin də başını ağrıdan sual olur. Çünki hər bir strukturun özlüyündə müsbət və mənfi tərəfləri var, eləcə də bəzən bu layihənin də qiymətinə təsir edə bilir(cuzi şəkildə). Bu günki yazımızda hər iki yanaşmanın müsbət və mənfi cəhətlərindən, nə zaman istifadəli edilməlidirlər kimi mövzulardan danışacaq və yuxarıdakı suala bacara bildiyimiz qədər cavab verməyə çalışacağıq. Elə isə gəlin ilk sualımızı verək. Nədir bu MVC?
MVC 1970-ci illərdə Trygve Reenskaug tərəfindən yaradılıb və Model-View-Controller sözlərinin baş hərflərindən ibarətdir. Bəzən sadəcə veb dünyasında olduğu düşünülsə də özlüyündə bir dizayn pattern-dir, bu o deməkdir ki, biz MVC-ni konsol layihədə belə tətbiq edə bilərik. Aşağıda hər parçanın kiçik də olsa izahını tapa bilərsiniz:
Son məhsuldur. İstifadəçinin görəcəyi html, css, js kodları bu bölmədə yazılır və istifadəçiyə response olaraq göndərilir. C#(ASP.Net MVC), Java(Spring Boot), Php(Laravel) kimi dillərin frameworkləri(bir növ kitabxanaları deyə bilərik) özlərində Viewları fərqli fayl tipləri təklif edirlər. Məsələn C#-da bu fayl .cshtml, Java-da .jsp, Php-də isə .blade.php-dir. Tiplər fərqli olmağına baxmayaraq demək olar hər birində rahatlıqla html, css, js kodları yaza bilərik. Əsas fərq isə dinamikləşdirmə məsələsindədir. Məsələn deyək ki, sistemimizdə 50 məhsul var və bunların hər birini əlimizlə aşağıdakı kimi yazmaqdansa:
<ul>
<li>
<h3>Məhsul 1</h3>
<img src="mehsul1.png" />
</li>
<li>
<h3>Məhsul 2</h3>
<img src="mehsul2.png" />
</li>
<li>
<h3>Məhsul 3</h3>
<img src="mehsul3.png" />
</li>
<li>
<h3>Məhsul 3</h3>
<img src="mehsul3.png" />
</li>
<!-- Məhsulların ardı ... -->
</ul>
Biz bu fərqli fayl tiplərində, sadə proqramlaşdırma məntiqi işlədərək dinamikləşdirmə əldə edə bilərik:
@{
var mehsullar = new List<Mehsul>()
{
new ()
{
Name = "Məhsul 1",
ImageUrl = "mehsul1.png"
},
new ()
{
Name = "Məhsul 2",
ImageUrl = "mehsul2.png"
},
new ()
{
Name = "Məhsul 3",
ImageUrl = "mehsul3.png"
}
// mehsullarin ardi
};
}
<ul>
@foreach(var mehsul in mehsullar)
{
<li>
<h3>Məhsul 1</h3>
<img src='mehsul1.png'/>
</li>
}
</ul>
Bəzi front-endçi dostlarımız bunu React, Angular kimi texnologiyalar ilə də edə bilirik deyə bilərlər. Haqlıdırlar, elə bu məqalə də həmin texnologiyaların fərqləri üçündür. Qısaca desək, View istifadəçiyə çatan bölmədir. Biz veb aplikasiyaları yazarkən View-ları Views adlı qovluqda saxlamağı tərcih edirik. Elə isə keçək modelə.
Modellər bizim sistemlərdə çox vacib yer tuturlar, bəzən onların Entity kimi adlandırıldığını da görə bilərsiniz. Databazada olan cədvəllərimizin kod ilə modellənmiş versiyasıdır. Məsələn, databazamızda şagirdlər adlı cədvəlimiz ola bilər və biz sistemimizdə bunu şagird modeli kimi saxlaya(və ya başqa sözlə modelləyə bilərik). Yuxarıdakı nümunədə isə Mehsul adlı bir tipin istifadə edildiyini gördük elə həmin nümunədə Mehsul bizim modelimizdir. Çox vaxtı Modelləri Models adlı qovluqda saxlamaq tərcih edilir. Sual yarana bilər ki, bəs bütün bu model-lər və view-lar arasında əlaqəni kim bərpa edir, yəni məsələn lazımi məlumatlar databazadan viewlara necə gəlir və ya necə istifadəçiyə göndərilir? Bütün bu prosessləri kim/kimlər idarə edir? Bunun cavabı isə Controller-dədir.
Controller-i ortadakı körpü kimi fikirləşmək olar. Bu dostumuz, lazım olan məlumatları View-lara daşıyır və ya lazım olan View-u istifadəçiyə göndərir. İşi sadə görünsə də ən ağır iş həmişə controller-in üstündə olur. Lakin controller-dən bu yükü azaltmaq üçün Action adlı bir termin var ki, işləri daha da atomikləşdirir. Misal olaraq aşağıdakı controller nümunəsinə baxa bilərik:
public class AccountController : Controller
{
// controllerin evveli
[HttpPost]
public async Task<IActionResult> Register(RegisterVm registerVm)
{
if (!ModelState.IsValid)
return View(registerVm);
AppUser usr = new()
{
Email = registerVm.Email,
UserName = registerVm.UserName
};
var res = await _userManager.CreateAsync(usr, registerVm.Password);
await _userManager.AddToRoleAsync(usr, "Admin");
return RedirectToAction("Login", "Account");
}
// controllerin ardi
}
Istifadəçini qeydiyyatdan keçirmək üçün olan sadə bir Controller Action-dur. Gördüyünüz kimi bəzən View ilə danışır bəzən isə Model-lərlə.
Müsbət tərəfləri:
Mənfi tərəfləri:
API sözü ilk dəfə 1940-cı illərdə ortaya çıxsa da məhşurlaşması MVC kimi 1970-ci illərə təsir edir. Adını Application Programming Interface sözlərinin baş hərflərindən götürüb. Təkcə veb dünyasında deyil proqramlaşdırmanın demək olar istənilən hissəsinə təsir edən məhvumdur. Veb dünyasında isə API-lər istifadə edilərək front-end və back-end proqramçılar ayrıla bilir. Beləcə hər iki tərəf bir-birilərindən "asılı olmadan" proyekti yaza bilirlər. C# dili ilə də Web API-lər yazmaq mümkündür. Hətta maraqlı tərəfi odur ki, MVC məntiqinə çox oxşar olduğu üçün MVC proqramçıları rahatlıqla WEB API-lər yaza bilirlər. API-lər özlərində isə 2 yerə bölünürlər: SOAP və RESTful.
Açılışı Simple Object Access Protocol-dur. RESTful API-lərdən öncə sahəni dominant edən API növlərindən olubdur ki, hələ də mobil aplikasiya üçün yazılan API-ların bir çoxunda istifadə edilir. Lakin, zaman keçdikcə RESTful API-lər SOAP-ları əvəz edirlər(mobildə belə). Bunun səbəbi isə SOAP-ın məlumat transferi üçün XML(extensible markup language) istifadə etməsidir, hansı ki özlüyündə çox ağırdır. Bu da bizim HTTP request və responsların həcmini böyüdür.
Açılışı Representational State Transfer-dən gəlir. SOAP-a görə tərcih edilməsinin əsas səbəbi özündə JSON(JavaScript Object Notation) formatı işlətməyidir. Adında JavaScript sözünün olmasına baxmayaraq demək olar bütün proqramlaşdırma dilləri tərəfindən tanınan bir formatdır. Hətta belə bir bənzətmə belə verə bilərik ki, proqramlaşdırma dünyasının ingilis dilidir. JSON formatını işlətməklə HTTP requestlər və responslarımızın daha yüngül olmasına nail oluruq. Əgər JSON-dan da yüngül format axtarırsınızsa ProtoBuff-lara baxa bilərsiniz(bu ayrı yazımızın mövzusudur🤠)
İndi isə keçək pis və yaxşı tərəflərinə.
Müsbət tərəfləri:
Mənfi tərəfləri:
Gördüyünüz kimi hər nə qədər, API-nin müsbət tərəfləri cəlbedici görünsə də, mənfi cəhətləri də nəzərə alınmalıdır. O zaman ilk sualımıza cavab verək?
Bütün müsbət və mənfi cəhətləri analiz edəndə belə bir nəticəyə varırıq ki, hər yanaşma bizə fərqli situasiyalarda dəstək ola bilər.
Məqaləni hazırladı: Cəlil Verdiyev
Təsdiqlədi: Əlinemət İsiyev
