Швидка веб - розробка з NReco - SEO Blog - все про пошукову оптимізацію та веб розробку українською.

Швидка веб - розробка з NReco

Ліричний вступ Написати одну хорошу строчку коду , в общем- то , легко : вона зрозуміла , робить те , що потрібно , її легко прочитати і зрозуміти (якщо це не строчка на Perl) . Коли строчок багато, ситуація радикально змінюється в гірший бік : реальність така , що проектний код зазвичай пишеться в умовах жорстких часових обмежень далеко не клонами Джона Скиту , і замість гарного коду « маємо те, що маємо» . Іншими словами , проектний код - це біль . Чим його менше , тим краще.

Ми використовуємо фреймворки , щоб створювати надійні архітектурні та інфраструктурні рішення і не писати зайвий код в проекті ( « велосипеди »). Ми використовуємо компоненти , щоб отримати необхідну функціональність через збірку замість написання одноразової проектної реалізації « з нуля». Повторне використання коду - це срібна куля в боротьбі з проблемою збільшення його кількості . Ми використовуємо повний арсенал ( OOP , FP , CBD , TDD , DDD , MDD і т.д.) для організації коду таким чином , щоб зменшити кількість коду , уникнути дублювання та забезпечити ті чи інші його характеристики . У цій статті я хочу розповісти про новий інструмент для організації ефективного повторного використання артефактів як в рамках одного проекту , так і між різними проектами . Інструмент називається NReco ( для платформи .NET) , і з його допомогою можна :
- генерувати прототипи веб - додатків за кілька хвилин ;
- швидко розробляти повнофункціональні бізнес -додатки і адмінки з написанням мінімуму проектного коду (до х10 раз швидше, в порівнянні c класичної розробкою на WebForms/MVC ) ;
- збільшити ступінь повторного використання як усередині проектів , так і між різними проектами в одній організації (зменшення витрат = профіт ) ;
- радикально зменшити витрати та покращити якість при розробці проектів через організацію продуктової лінії за допомогою фабрики програм ( software factory ) .

NReco - це .NET проект з відкритим вихідним кодом , і він повністю безкоштовний для комерційного використання. Трохи історії
У далекому 2006 році ми в NewtonIdeas розробляли досить складне BPM - рішення для управління процесами аудитів в галузі забезпечення якості. Згідно з традицією , мався на наявності 23 - річний сеньйор (я ) і команда зі скромним досвідом .NET і ASP.NET WebForms зокрема.
Вже тоді ми використовували Spring - подібний IoC - контейнер власного виробництва , оскільки підходящого контейнера з XML - конфігурацією тоді не було ( Spring.NET з'явився пізніше). Інверсія управління допомагала в деякій мірі зменшити зв'язність проектного коду та забезпечити подібність порядку на рівнях шару даних і бізнес - логіки , правда , при цьому зростаючі обсяги XML - конфігурації компонентів самі по собі ставали проблемою. З UI була взагалі біда : виростали ASCX - шаблони розміром 60kb і більше , де розмножувалися вкладені Repeater - и і химерно працюючі databinding -вирази . Щоб внести мінімальна зміна , вимагалося вдумливе вивчення всієї цієї ковбаси , і це в підсумку займало непристойне кількість часу у розробників . У мене був хороший досвід використання XSLT (на початку 2000 - х була мода генерувати HTML - сторінки за допомогою XSLT на сервері ) , і виникла думка використовувати перевірені інструменти для організації максимально легкого процесу створення моделей і опису їх трансформацій . Що може бути простіше опису моделі у вигляді XML , її мета- моделі у вигляді XSD і трансформації у вигляді XSL ? Ми змогли описувати бізнес логіку декларативно у вигляді простих XML - файлів і генерували реалізацію у вигляді композиції спеціальних компонентів , описану за допомогою XML - конфігурації IoC - контейнера ( підхід був описаний в статті журналу « Кібернетика і системний аналіз ») . Ми пішли далі , почали описувати UI у вигляді XML - моделей і генерували ASCX мегабайтами . Настали на всі граблі , на які могли настати . В проектах почали з'являтися згенеровані XML - конфігурації розміром 40mb і більше ; був момент , коли більша частина системи задавалася у вигляді складних XML структур , після чого прийшло розуміння , що не все XML - моделі однаково корисні.

В 2008 частина напрацювань були відкриті у вигляді open - source проекту Open NIC.NET ( інфраструктурні компоненти ) , а все , що стосувалося MDD , було написано з чистого аркуша і названо NReco . Поділ умовне і просто склалося історично : насправді обидва проекти розвивалися синхронно , як єдине ціле. Ця перша версія використовувалася (і розвивалася ) для розробки десятків веб - проектів ( 2009-2013 ) . Незважаючи на відкритість і очевидний ( для нас) економічний ефект , технологія була все ще досить складною і заплутаною (з різних причин ) для того , щоб її використав хтось крім нашої команди. У результаті тотального рефакторінга і переосмислення накопичених напрацювань з'явилася повністю нова версія NReco 2.0 , яка , я сподіваюся , варта уваги широкої аудиторії . Генерація NReco - програми При проектуванні NReco 2.0 я старався максимально використовувати існуючу інфраструктуру VisualStudio . Наприклад , при редагуванні XML - моделей працює вбудована в VS - валідація та підказки по XML - схемам , а всі компоненти оформлені у вигляді NuGet - пакетів з активним використанням XDT . Інфраструктурні компоненти , такі як IoC - контейнер або DALC , є повністю автономними і можуть бути використані в будь-якому .NET проекті.

Почати знайомство з NReco можна одним з 2 - х способів :
- Клонувати Git - репозиторій code.google.com/p/nreco ( бранч nreco2 ) і запустити кілька прикладів
- Згенерувати готове ASP.NET додаток у вигляді NuGet - пакета . Додаткову інформацію можна виявити на сайті nrecosite.com . Розраховувати на повноцінну документацію поки не доводиться : можливо , у мене з'явиться вільний час (ага , а курс знову буде 8грн) , або , може , з'являться нові контриб'ютор , або щось ще . З іншого боку , завдяки наявності XML - схем і опису трансформацій у вигляді XSL цілком посильно розібратися , що до чого. Розглянемо процес генерації ASP.NET як найбільш ефектний . Припустимо , нам потрібен прототип для гіпотетичної міні - CRM з контактами клієнтів і супутніми довідниками . Щоб не ускладнювати процес налаштуванням бази , змінимо БД на SQLite : Загальні налаштування дозволяють відразу підключити необхідні пакети і конфігурацію для фіч , які будуть потрібні в проекті ( при необхідності , їх можна доставити і пізніше). Далі розташований конструктор для визначення схеми даних і CRUD - інтерфейсу . Визначимо таблиці для довідників : Для таблиць - довідників CRUD Type виберемо Editable List , щоб зручно було набити значення прямо в списку . Також додамо таблицю з клієнтами , яка використовуватиме певні вище довідники : Генерація додатки - це теж трансформація XML - моделі (формується по введених даних ) в набір файлів ( в основному інших XML - моделей ) , які сформують унікальний NuGet - пакет для установки в проект VisualStudio . Установка згенерованого пакета не повинна викликати особливих труднощів: після генерації відображається докладна покрокова інструкція . В цілях тестування найпростіше створити в VisualStudio 2013 ( Express for Web підійде ) новий ASP.NET Application Project з шаблоном Empty і core references для WebForms , і відразу встановити щойно скачаний NuGet - пакет (момент : VS Update 2 повинен бути встановлений , інакше при установці пакета вивалиться помилка ) .

Якщо все пройшло успішно , можна запустити додаток натисканням F5 , при першому запуску додаток само створить файл з SQLite базою і инициализирует її схему . В результаті повинна відобразитися логін - сторінка: У базі за замовчуванням створена обліковий запис « admin » з паролем « 1 » . Після входу наповнюємо довідники :

І створюємо запис для клієнта : Список клієнтів , сторінка з деталями і редагуванням додаються. Власне , це і є обіцяний (абсолютно працездатний ) прототип , який можна отримати за кілька хвилин. Все артефакти представлені у вигляді XML - моделей і легко піддаються розширенню/модифікації шляхом редагування в VisualStudio ; розглянемо процес додавання нового поля: Після зміни XML - моделі треба повторити процес трансформації моделі , який відбувається при кожній збірці проекту. Технічно це реалізовано особливим MSBuild Task - ом , який викликається на AfterBuild проекту для всіх файлів проекту, де вказано Build Action = XmlModel або які мають розширення * .dsm.config . Цей Task очікує, що у кожного файлу з XML - моделями буде processing instruction з інформацією про те , як трансформувати цю модель. Наприклад , для config/dsm/data - schema.dsm.config (яка включає змінений файл clients.xml через XInclude ) ця інструкція виглядає так : & lt ; ? xml - stylesheet type = " text/xsl " href = "../ xsl/model - data - schema.xsl " output - file = "../ common/_generated_data - schema.xml.config " ? & gt ; Нестандартний атрибут цієї PI output - file використовується для вказівки імені файлу , де повинен бути збережений результат трансформації . Відразу відзначу , що в результатом трансформації може бути і безліч файлів ( наприклад для моделі config/dsm/layouts.dsm.config ) . Бінго ! Цього достатньо , щоб вказати, які XML - моделі трансформувати , яким чином і де розташувати результат. Все просто до непристойності , а значить , з цим зможе розібратися навіть початківець девелопер . Звичайно , вважати XSL повноцінною мовою трансформацій можна тільки для перетворень XML ? XML , проте у разі ASP.NET - додатка цього цілком достатньо: конфігурація IoC -контейнера описується за допомогою XML , а UI - шаблони ( ASPX/ASCX ) описуються XML -подібні способом. Взагалі кажучи через XSL можна генерувати будь-які текстові артефакти ( в тому числі і JavaScript/C # код ) , але в цьому випадку XSL не зможе забезпечити деякі характеристики трансформації ( наприклад , синтаксичну коректність результату) . Основна магія відбувається в XSL - правилах і компонентах , композиція яких призводить до появи необхідної функціональності . Під капотом NReco залишилося ще багато цікавого: механізми зв'язування з використанням функціональних залежностей , автоматичне узгодження типів (і делегатів !) , подієво -орієнтована організація логіки додатка і всяке таке. У цій вступній статті немає можливості розкрити всі технічні деталі фреймворка , який створювався багато років. Але я сподіваюся , що викладеного матеріалу достатньо, щоб викликати інтерес до проекту NReco ; особливо стійкі можуть продовжити знайомство з інструментом через вивчення вихідних кодів і прикладів/тестів , а також просто експериментуючи . Можливості Список того , що можна зробити з XML - моделями «з коробки » , не обмежується найпростішими CRUD -ами :
- можна задавати довільні конфігурації рендеринга ( в кілька колонок , в табах і т.д . ) ; - до списків можна визначати фільтри , у тому числі досить складні (умови на кілька полів з ??AND/OR ) ;
- використовувати масові операції в списках ;
- використовувати довільні UserControl - и для рендеринга кастомних елементів або редакторів полів ;
- декларативно описувати залежності між редакторами на формах ( класика жанру , 2 залежних дропдауна , в такому дусі ) ;
- визначати нові елементи в XML - моделях ( наприклад , для опису специфічного оформлення в конкретному проекті) ;
- відображати у вигляді діалогів , абстрактні форми ( не прив'язані до якоїсь таблиці ; наприклад , для бізнес - дій ) ;
- задавати довільні SQL - view для використання в провайдерах даних і UI ;
- централізовано обмежувати доступ до даних на рівні SQL запитів ;
- включити вбудовану реалізацію відстеження змін даних в БД ( change data capture/change data tracking ) . Цей мінімальний набір фичей вже дозволяє використовувати NReco для швидкої побудови адмінок і різноманітних бізнес - додатків (як мінімум , їх прототипів ) . Надалі список доступних XML - моделей буде розширений : деякі класні фічі з попередньої версії NReco ( наприклад , XML -модель для опису індексації та пошуку за допомогою Lucene.NEТ ) все ще чекають рефакторінга та оформлення у вигляді NuGet - пакетів .

Крім готових моделей для опису шару даних і UI , можна скористатися інфраструктурою NReco для визначення своїх XML - моделей та їх трансформацій в результуючі файли ASP.NET додатки . Таким чином можна організувати повторне використання артефактів як всередині проекту , так і між проектами , виділяючи цілі блоки функціональності у вигляді NuGet - пакетів . Замість висновку Мені здається , розробка в аутсорсингу найбільш брутальна . Тимчасові та бюджетні обмеження завжди на першому місці , і будь-який новий підхід проходить жорстку апробацію реальністю і економічною доцільністю. Кожен по -своєму , але ми все таки використовуємо об'єктно-орієнтована і компонент - орієнтований підходи в щоденній розробці . З модель - орієнтованої розробкою ( MDD ) якось не склалося - мабуть , вся справа в реалізації . Технологія NReco сформувалася і вижила в суворих умовах українського аутсорсингу ( більш того , в невеликої команді , де кожна людина на рахунку ) ; вона не претендує на фундаментальність (як наприклад , MDA від OMG ) , але при цьому дозволяє отримати вигоди від використання підходу MDD в абсолютно звичайних веб - проектах вже зараз , з мінімальними витратами на впровадження та навчання .

Опубліковано: 29/09/14 @ 06:26
Розділ Програмування

SEO Блог

Швидка веб - розробка з NReco

Рекомендуємо: