n-layered-arxitekturada-istisna-hallarinin-emali

N-Layered arxitekturada istisna hallarının emalı

Proqram təminatı hazırlayan zaman əsas meyarımız həmişə keyfiyyətli proqram hazırlamaq olmalıdır. Bu məqsədə xidmət etmək üçün isə riayət etməli olduğumuz əsas meyarlardan biri robustness prinsipidir. Prinsipin təməlində dayanan əsas ideya odur ki, yazdığımız proqram tələblərdə nəzərdə tutulmuş hallardan kənarda yəni `anormal` situasiyalarda ayaqda qala bilsin, qəzalı vəziyyətə düşməsin. İlk başdan sadə səslənsə də, əksər hallarda buna riayət etmək əlavə iş yükü olaraq başa gəlir.

               Bu məqalədə N-Layered(N-örtüklü/qatmanlı) arxitekturalı proqram təminatında istisna hallarının emal olunması(exception handling) haqqında danışacağam.

               İşlədiyimiz proyektlərdən birində, N-Layered(N-örtüklü/qatmanlı)  strukturlu arxitektura ilə işləyirəm. Həmin proqram təminatı əsasən WCF|old service(.asmx) xarakterli servislər üzərinə müasir standardlı Azure Functions yazmaq məqsədi güdür. Qısacası wapper(обертка) yazıb, kommunasiya adapterini dəyişirik.

Hər bir layer öz üzərinə düşən modul işini inkapsulyasiya edərək yuxarı layer-ə sadəcə lazımi informasiyaları ötürür. Amma lazımi informasiyalar ötürərkən istisna hallarını həmişə göz önündə saxlamaq lazımdır. Əgər istisna hallarını hər bir layer-də düzgün emal etməsək nəticədə yuxarı layer aşağı layer-in iş prinsipi , daxili realizasiyası haqda məlumata malik olacaq. Hər bir layer öz modulyar işini maksimum səviyyədə inkapsulyasiya etməli, yuxarı layerlərə sadəcə bilməli olduğu informasiyaları ötürməlidir. Layerlər bir-birinin işi haqda nə qədər minimal məlumata malik olsa bir oqədər yaxşıdır. İşin arxitektur tərəflərinə getmədən, məqsəddən yayınmadan birbaşa realizasiyaya keçək.

Yuxarı səviyyədə arxitekturaya baxış (Bird-eye view)

PS: İşi asanlaşdırmaq və proyektdən-proyektdə dəyişdiyi üçün bəzi layerlər sadəcə A,B şəklində adlandırılıb.

               İlk öncə məsələyə istisnalar emal olunmamışdan əvvəlki vəziyyət kimi baxaq. Aşağı  Layer sadəcə try..catch vasitəsilə öz layer-ində olan istisna hallarını emal edir və geriyə exception-ı qaytarır. Bu ö deməkdir ki, layer-də baş verən yalnız ona aid daxili realizasiya istisnaları baş verərsə təəssüfki yuxarı layer bu haqda məlumata malik olacaq, bu da iş yükünün səpələnməsinə gətirib çıxardacaq.

try
{
    //do some operation
    //more operation
}
catch(Exception exp)
{
    _logger.WriteToLog(exp.Message);
    throw;
}

Azure funskiyalara sorğu verən zaman əgər istisna halı yaranırsa ozaman misalçün Postman-da konkret olaraq web servis haqqında detallı error məlumatları görəcəyik. Səbəb isə hər bir layer-in özünəməxsus istisna hallarını emal etməməsidir.

              

Bu kimi problemleri həll etmək üçün vəziyyətdən asılı olaraq custom exception handling mexanizminə ehtiyacımız var. Çünki hər layer yuxarıya yalnız bilməli olduğu qədər informasiya ötürməlidir. Buna friendly exception throwing də deyə bilərik.

               Problemi həll etmək üçün alt layerdə özəl bir exception handling klası hazırladım.


Layerdə baş verən hər bir istisna halını friendly exception-ımıza ötürərək həmin exceptiondan yalnız kontrakt əsasında yuxarı layer-ə lazım olan məlumatı extract edib ötürür.

               Indi isə həmin istisna halını Azure function-da emal etmək lazım idi. Yeni yaratdığım exception klaslarını alt layerdə verdiyimə görə yuxarı layer sadəcə referans verərək həmin exception klasını istifadə edə bilir. (ServiceException)  try..catch blokunda qalxan exceptionı handle edib(şəkildə 1)  başqa olan istisna halı üçün isə( şəkildə 2) yenə istisna klasını wrapper kimi istifadə etdim. Bu imkan verdiki ,BadResponseErrorResult klasımız lazımi məlumatları exception klasından alıb istifadəçiyə göstərsin.

BadResponseErrorResult klası da manual olaraq yaradılmış klasdır. Əsas işi Azur funksiyalarda istisna halı baş verərsə onu istifadəçiyə kontrakta uyğun əks etdirsin.

BadResponseErrorResult ServiceException üçün Azure functions layerində örtük rolunda çıxış edir. Əsas işi ServiceException-dan məlumatları alıb user friendly formada istifadəçiyə əks etdirməkdir.

İcmal:

Yekun olaraq nəzərdə saxlamaq lazımdır ki, N-Layered arxitektura ilə işləyən zaman istisna hallarını düzgün emal etmək ən başlıca məsələlərədn biridir. Bununçün custom handling mexanizmi(tələbdən asılı olaraq) yaza bilər, yuxarı layer-lərə bilməli olduğu qədər məlumat verə bilərsiniz. Bu sabah arxitekturada major və minor dəyişiklik zamanı işinizi asanlaşdıracaq, məsuliyyət bğlgüsünə xidət edəcək.

 

 

 

Tural

Tural Süleymani

Süleymani Tural Microsoft-un MCSD statuslu mütəxəssisidir, 2008-ci ildən bu yana proqramlaşdırma üzrə tədris aparır

Müəllifin bu dildə ən son postları

Bu yazıları da bəyənə bilərsiniz