Дивимось на MVC Framework (Частина 1)

Вчора я вже писав що вийшла перша CTP для MVC Framework. Зрозуміло що очікувати від неї всього що було задекларовано важко, але все одно дуже цікаво. От вчора ввечері я і вирішив покопатись у внтурощах.

Ламаючи традиції розпочну з поганого.

Проблема з назвою контролера

Тут використовується таблиця де на початку реєструються усі контролери, ключ для реєстрації це ім'я класу без неймспесу, і від нього ще відкушують 10 символів. Зрозуміло що назвати однаково два контролери не можливо. Називати контролери без постфіксу Controller теж не можливо. Добра новина це те що цей функціонал можна повністю замінити. Приклад такої зміни - Create your own IRouteHandler.

Проблема з типізацією параметрів

Добрі практики іноді не такі вже й добрі. Майже усі приклади використовують анонімні типи для генерації параметрів. Трабла в тому що будь яка назва параметру компілюється... Тобто фактично цей анонімний тип використовується у якості нетипізованого словника з параметрами! Інші приклади наводять приклад використання лямбда експрешенів. Добре тут вже є типізованість. Але мене цікавить питання які асоціації викликає запис (картинка взята з блогу ScottGu):

В мене асоціації будь які, але жодної з тим що лямбда експрешшен буде розібрано, і потім по дереву побудовано правильний URL.

Як завжди є і добра новина (ексклюзивна ;)). Достатньо створити клас, який інкапсулює в собі параметри. Щось на кшталт контракту для URLа. Тепер ми підтримуємо і типізованість, і рефакторінг, і все для чого оті класи потрібні.

Проблема з реєстрацією роутінгу (навіть прекладати не буду)

Створивши новий проект потрапляєш у Global.asax в якому в Application_Start і реєструються усі роути. Тобто у нас є дуже гарне розподілення на модулі, і всі ці модулі залежать від одного, від Global.asax. Цікаве рішення. Якщо б це була фізична залежність, то усі статичні аналізатори просто померли від такого коуплінгу... Нажаль поки що ці тулзи аналізують тільки фізичні залежності. Як завжди рішення на поверхні. Тут вже можна вигадувати будь що. Наприклад кожен модуль буде мати свій клас на кшталт RouterInitializer який і буде налаштовувати роути для свого модуля. А Global.asax в свою чергу буде вже маніпулювати цими класами. Тепер головне залишилось якось розкермувати(?) проблему з видимістю, тобто при бажанні(або хтось недодивився) модуль може перетягнути на себе URLи іншого.

Проблема з PostBack

Я десь читав що підтримка постбеків буде. Так от її немає, і схоже і не буде. Як на мене це правильне рішення. Схоже що прямої міграції не буде. Хоча MVC та WinForms працюють side-by-side в межах одного додатку, а тому будуть можливі сценарії або часткової міграції, або об'єднання в одному додатку MVC та WinForms частин.

Проблема з плагінами

На Alt.Net пропливала така фішка, що можна буде писати веб додаток з декількох окремих модулей. Тобто усе включно з в'юхами можна було б впіхнути в ассемблю, і вже зкомпільовану асемблю використовувати в доадтку. Зрозуміло що це відкриває достатньо великі можливості. Теоретично ця фішка можлива. Тобто це не проблема написати свій контролер який буде отримувати темплейт з ресурсів, чи щось на кшталт цього. Але ось для aspx сторінок цього не зробили. Тому поки що такої можливості, принаймні вбудованої, немає. Як завжди добра новина, що це можна написати!

Просто проблема

Якщо в студії не встановлено сторінку по замовчуванню, то Run викликає поточну сторінку. Для MVC сторінки це означає що до неї прийде запит, але вона не буде проініціалізована. На прикінці всього отримуємо виключення на кшталт NullReferenceException. Негаразд. Ну і погано що до цих сторінок можна дістатися.

Покищо це все, далі буде (я ще нічого доброго не писав, хоча відчуваю і погане ще буде), сьогодні спробую написати невеличкий додаток. А ще потрібно буде написати ControllerFactory для ObjectBuilder і викласти його в MVCContrib.