Underlog - the simple things

Та да си дойдем на темата – не обичам лук. Специално пресния. Самото му наличие в стаята ми наслоява неприятни неща по гърлото. Бе като цяло голям дискомфорт. По ирония на съдбата точно лука е горе долу като това, дето ще се напъна да обяснявам. Или иначе казано многослойната архитектура в уеб апликациите.

Защо?

Ами за мен лично ползите са основно гъвкавостта и асинхронността, дефрагментирането на работата, фокусирането и изследването на проблемите в специфичния за тях аспект – бил той логика или презентация.

Да поясним

Гъвкавост и асоинхронност – слоевете могат да бъдат развивани независимо един от друг, да бъдат сверявани към проектоизискванията, стига да има ясна конвенция за крайната сглобка, (разписана в първоначалния план на проекта разбира се). И да додам конкретен пример – ако изолираме имплементацията на the look and feel и the design concept изцяло в CSS, то е много възможно да работим върху графичния дизайн на проекта до един късен етап от неговото развитие, без да се притесняваме, че HTML частта е вече написана. А защо да не го дизайнем и накрая – когато всичко е готово и разглеждаме нашите идеи в реален изглед?

По същия начин стои въпроса и с потребителския интерфейс (да подметна – тук е добро място за валидация) и бизнес слоя – те биват свързвани посредством Page controller (Какво е това ли? Кой не е чел MSDN за ‘неска? Гошо, я вземи мечето!) който в най общия случай data bind-ва и отговаря за обработката на събитията, предизвикани от control паплачта из страницата.

От друга страна пък бизнес обектите да не оперират и да не „знаят” за структурата на източника на данни (тука понякога спорим по въпроса с колегата, ама аз клякам пред 130те кила и 6те години опит) – заговаряме за абстракция върху SQL заявките, или data access слоя – който от своя страна пък оперира с пренос превоза (справка: дизайна на ado.net и data access helper от Microsoft). Понякога този data access може да се направи в тлъст слой от съхранени процедури, които скриват реалната структура на базата данни и се грижат за целостта на данните. Ако нямате желание за това – изкарайте абстракция на схемата на базата в програмния код, и надградете действията върху базата там. Но във всеки случай SQL заявките не трябва да бъдат пръснати из слоевете, че отиде лучената история.

Тука разбира се идва и момента с това как комуникират отделните слоеве и по какъв начин разнасяме данните през слоевете – ами това зависи изцяло от конкретната технология и framework – варианти на тема recordset, typed dataset, custom collection, xml бол. Важното е когато данните биват досурнати до UI слоя, потребителските контроли да знаят какво да ги правят и как да ги показват.

Защо дефрагментираме работата?

Ами защото вместо да цепим приложението на features и раздадем всяка функционалност на отделен програмист, в резултат на което почерка му ясно остава в отделните блокове на приложението, ние го разделяме на лучени люспи – като по този начин форсираме екипна работа (да, много важно) и позволяваме на отделните девелопери да фокусират върху определена технология. Защото не може всеки да е ДБ дизайнер, SQL гуру, прекрасен .net програмист, и същевременно да чете Зелдман и Пеннер и да се вълнува от реалната реализация на концепцията на графичния дизайнер.

Итерациите

И тука идва проблема на погледа върху този процес като подчаст от големия проекто процес – сверяването на това дето го мажем с това дето аджеба трябвало да стане. Което аз лично го правя след всеки един слой – правиш Look and feel – търчи да показваш на дизайнера дали си въплътил неговите въжделения и пращаш на клиента за заверка. Изследваш UIто и UI процеса посредством прототипи и жичкорамки (wireframes) – тестваш с потребителите. Правиш бизнес слоя – разпечатка на методите на обектите и търчиш при мениджъра (а, ако си е направил труда да ги разпише работите - не, тогава просто прочиташ пак спека). Дизайнваш базата и подготвяш data access слоя – айде пак сверка.

Проблемите

От гледна точка на бързо действие и скорост на работа по проекта това не е най оптималното – най-малкото разкъсваш работата върху отделните features. Да не говорим, че ако нямаш готов и проверен framework, на когото да стъпиш подобно лучено разслояване е жива отрепия. Но това се компенсира в качество и гъвкавост. Откъм скорост на приложението нещата са – зависи. Но понякога неуместен дизайн и лошо замислена абстракция в data access областта може да вкара много лош автогол.

Колегата скоро извади едно решение, което донякъде „сплескваше” реализацията на всеки един от слоевете до PHP – и наистина откъм програмистко бързодействие нещата са много добре – пишеш само на един език (А не на CSS, JavaScript, HTML, ActionScript, PHP, SQL). Тук идва въпроса обаче, че всяка една подобна абстракция неминуемо връзва ръцете и не дава ПЪЛНИЯ достъп до възможностите на всеки един от тези езици.  Пък и лично аз се чувствам комфортно да реализирам UI слоя посредством HTML и CSS, а да упражнявам контрол върху базата посредством сурови SQL заявки.

И разбира се – проблемът с екипа. Ако хората не се сработят – чакай да нагодиш CSS-а на единия към HTML-а на другия…

ПП – търсенето продължава. Горното са чисто субективни размишления, непретендиращи за обективност или достоверност…

Този пост е публикуван на Събота, Май 22nd, 2004 в 12:00 am и е в категория Uncategorized. Можеш да следиш коментарите по rss RSS 2.0. Коментирай, или пиши за това на твоя сайт.