1. Романс о романсе. О нем речь уже шла вот тут.
2. Joy of Bossa Nova чешского композитора Jiří Jirmal. Эту же композицию видел под названием Shiny Day. Здесь можно посмотреть и послушать, как ее играет автор.
3. Nuages Джанго Рейнхардта. Рекомендую также к просмотру в исполнении Rosenberg Trio.
4. Suite Azure, часть 2: Danza. Это еще одна композиция by Jiří Jirmal.

Вчера меня снова потянуло на ExtJS. Видимо, жарища так влияет. Поковырявшись в интернете, я нашел черновую версию книги ExtJS in Action, загрузил ее в свой Sony Reader и стал читать. После прочтения трех первых глав пришло осознание того, насколько красиво там сделаны некоторые базовые вещи. В этой статейке я остановлюсь на двух моментах.

1. Config-объекты и xtypes

В ExtJS, если существует компонент, например, MyComponent, то у него обязательно есть родственник MyComponentConfig. Последний содержит все настройки компонента. И возможны два случая.

Либо он передается в конструктор MyComponent-у, и экземпляр MyCompoment создается немедленно. В этом случае такой объект называется config object.

Либо он содержится в коллекции элементов (родительского) контейнера. Тогда контейнер создаст компонент на основе конфигурации, когда в этом будет необходимость. В этом случае MyComponentConfig называют xtype.

Так как ExtJS - это Javascript библиотека, а Javascript - язык с нестрогой типизацией, то MyComponentConfig как такового нету. Вместо него используются Javascript plain objects с полем xtype.

Рассмотрим пример. Мы хотим создать textbox. Вот его настройки:

var fieldConfig = {
    xtype: 'textfield',
    fieldLabel: 'Your name',
    value: 'test'
};

Теперь можно создать textbox явно:

var field = new Ext.form.TextField(fieldConfig);
field.render(document.body);

А можно создать форму с текстбоксом вот так:

var form = new Ext.form.FormPanel({
    items: [ fieldConfig ]
});
form.render(document.body);

Во втором случае есть контейнер (FormPanel), и конфигурация текстбокса находится в коллекции items. Как видно, текстбокс никто не создает - его создаст контейнер.

Вроде бы ничего особенного, но смотрите, что дает нам эта схема:

a) Возможность комбинировать компоненты без каких либо ограничений

Опишу ситуацию на примере, который недавно наблюдал на работе. Допустим вы разработали некий BlazingFastControl. Он достаточно навороченный, у него 100 опций по управлению наворотами:

Прошло время. Надо развивать продукт, и вы решили написать вот такое:

Объединив BlazingFastControl и MegaDropDown, хотите получить некий BlazingFastLookup.

Но вот беда: надо дать пользователю возможность как-то настраивать внутренний компонент. И если настройки не были изолированы в отдельный объект BlazingFastConfig, то придется дублировать все 100 опций и писать глупый код по их копированию. Особенное зло ждет в .NET, где каждая property обычно обвешана десятком атрибутов.

b) Config-driven component assembly

По-русски это значит, что config-объекты - это готовый способ сериализации UI. То есть весь интерфейс или его куски можно описывать и хранить в JSON или в другом формате.

Вы скажете мол ничего удивительного - ASP.NET контролы тоже можно объявлять в разметке. Но есть нюанс:

c) Отложенное создание вложенных компонентов

Представьте себе следующий UI: tab-panel в тремя вкладками, и за каждой вкладкой скрывается целый мир компонентов.

Если это описать в виде config-объектов, то после запуска не будет нужды создавать тяжелые экземпляры всех компонентов. Достаточно будет создать только то, что видно на активной вкладке. А на остальные, может быть, никто и не переключится, и 2/3 компонентов не будут даже создаваться, а так и останутся в зачаточном состоянии. Это - большая экономия ресурсов!

Почитать еще можно на stackoverflow.

2. Layouts

В ExtJS есть контейнеры (Container), которые содержат элементы (items). То, как элементы будут отображаться внутри контейнера, диктует специальный объект Layout.

Объясню на абстрактном примере. Объявим контейнер и элемент так:

class Container {
    public Collection<IItem> Items { get; }
    public ILayout Layout { get;  }
}

interface IItem {
    string Text { get; }
}

Допустим, наше приложение имеет дело с документами:

class MyDocument : IItem {
    public string Title { get; set; }
    public string Content { get; set; }
    // ...
    string IItem.Text { get { return Title; } }
}

Можно создать Container, заполнить его MyDocument-ами. И с помощью разных реализаций ILayout получить меню, табы, nav bar, форму или что-то свое невообразимое.

Заключение

ExtJS демонстрирует удачное применение паттернов проектирования для обеспечения повторного использования, оптимизации и кастомизации. Если вы пишете компоненты, и еще не поздно принимать архитектурные решения, обратите внимание на описанные тут подходы!

Но чтобы (говорит мэтр) такой каталог был возможен, надо, чтобы каждая операция (сложение там, умножение…) имела четко определенную семантику. И один из спорных моментов касается операции “плюс”. Степанов хвастается, что ни разу в жизни нигде не сделал ни одного не-коммутативного плюса. Плюс должен быть коммутативен, точка. Действительно, перестановочному закону учили еще в первом классе школы: “при перестановке слагаемых сумма не меняется”, a + b = b + a.

Очевидно, что "сложение" + "строк" немедленно оказывается за рамками всей этой красоты. И подписка на события в C# (obj.Changed += myFunc) тоже. Получается, что Perl и PHP молодцы, потому что складывают строки $вот . $так, а другие языки нарушают свойства абелевых групп, и их разработчикам должно быть стыдно.

Но правильно ли все это? Действительно ли коммутативность должна быть главным свойством сложения?

Для обычного человека (в том числе и для рядового программиста, который и слышать не слышал ни о каких абелевых группах) основное свойство сложения, интуитивно понятное, заключается в том, что в результате что-то объединяется. Было у Леши 2 яблока, а у Сережи 3 - сложили и получили 5. К ста рублям прибавили 200 и получили 300. Было две строки - сложили и получили одну длинную. Был обработчик события - прибавили к нему еще один и получили составной обработчик.

Так что, несомненно, А. Степанов крутой чел, но при всем уважении позвольте закончить статью вот этой ссылкой.

Вполне логично иметь публичную часть веб-проекта на MVC, организованную по всем канонам семантической верстки и accessibility (как, например, stackoverflow.com), а внутренний админский интерфейс, состоящий преимущественно из скучного CRUD-а, сделать на WebForms с использованием облегчающих жизнь компонентов вроде ASPxGridView и ASPxTreeList.

Две технологии уживаются вместе без каких-либо проблем, но я хотел бы сделать акцент на использовании MVC именно в Web Site.

Не является секретом, что ASP.NET-проекты бывают двух типов: Web Site и Web Application. Они различаются способом организации проекта и моделью компиляции. Подробнее можно узнать в первоисточнике.

Мне больше нравятся проекты типа Web Site. Во-первых, потому что для просмотра отдельной страницы не надо собирать весь сайт, который может быть большим и долго компилироваться. Во-вторых, сама идея компиляции по запросу мне представляется более естественной для веба. Да, есть и недостатки, но я от них ни разу не страдал. Думаю, что для малых и средних сайтов Web Site - самое оно. Как говорится, сайт он и есть сайт.

Сегодня студия имеет шаблон только для ASP.NET MVC Web Application, но запустить MVC в контексте Web Site совсем не сложно. Достаточно проделать нижеследующие шаги:

1. Запустите студию, как минимум 2008-ю и создайте новый Web Site по шаблону Empty Web Site. Не забудьте выбрать язык C#, а то вам могут впарить бейсик по-дефолту
    
2. Добавьте ссылки на сборки: System.Web.Abstractions, System.Web.Mvc, System.Web.Routing. ASP.NET MVC должен быть либо установлен в вашей системе, либо у вас просто должна быть где-то под рукой эта сборка. После махинации, в сайте появится файл web.config
    
3. В секцию pages файла web.config для своего же удобства добавьте строки

   <namespaces>
       <add namespace="System.Web.Mvc"/>
       <add namespace="System.Web.Mvc.Ajax"/>
       <add namespace="System.Web.Mvc.Html" />
       <add namespace="System.Web.Routing"/>
       <add namespace="System.Linq"/>
       <add namespace="System.Collections.Generic"/>
   </namespaces>

    
4. Теперь заставьте работать routing. Для этого в web.config нужно добавить:

   <system.web>
       ...
       <httpModules>
           ...
           <add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
       </httpModules>
   </system.web>
   ...
   <system.webServer>
       <modules runAllManagedModulesForAllRequests="true">
           ...
           <add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
       </modules>
       <handlers>
           ...
           <add name="UrlRoutingHandler" preCondition="integratedMode" verb="*" path="UrlRouting.axd" type="System.Web.HttpForbiddenHandler, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
       </handlers>
   </system.webServer>

   Видно, что регистрируется Routing-модуль для Classic и Integrated режимов, устанавливается параметр runAllManagedModulesForAllRequests, чтобы модули запускались даже тех путей, которые сервер не нашел на диске. Я не понял, зачем нужен еще Handler для integrated-режима (последний add), но без него не работает.

   Хочу сказать, что эти настройки я придумал не сам, а подглядел в web.config из проекта Dynamic Data Web Site, который является одним из примеров использования роутинга в WebForms.

    
5. Добавьте в сайт класс App следующего вида:

   using System.Web.Mvc;
   using System.Web.Routing;
   
   public static class App {
   
       public static void RegisterRoutes() {
           var r = RouteTable.Routes;
           r.IgnoreRoute("{resource}.axd/{*pathInfo}");
           r.IgnoreRoute("{resource}.aspx/{*pathInfo}");
           r.MapRoute(
               "Default",
               "{controller}/{action}/{id}",
               new { controller = "Home", action = "Index", id = "" }
           );
       }
   
   }

   Бьюсь об заклад, что вы догадались, зачем это нужно. Тут вы будете регистрировать маршруты и держать разные другие настройки вашего приложения.

    
6. Добавьте в сайт файл Global.asax (Global Application Class), и на Application_Start позовите RegisterRoutes:

   <%@ Application Language="C#" %>
   
   <script runat="server">
   
       void Application_Start(object sender, EventArgs e) {
           App.RegisterRoutes();
       }
   
   </script>

    
7. Добавьте в сайт папку Views и внутрь положите вот такой web.config:

   <?xml version="1.0"?>
   <configuration>
     <system.web>
       <httpHandlers>
         <add path="*" verb="*"
             type="System.Web.HttpNotFoundHandler"/>
       </httpHandlers>
       <pages
           validateRequest="false"
           pageParserFilterType="System.Web.Mvc.ViewTypeParserFilter, System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
           pageBaseType="System.Web.Mvc.ViewPage, System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
           userControlBaseType="System.Web.Mvc.ViewUserControl, System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
         <controls>
           <add assembly="System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" namespace="System.Web.Mvc" tagPrefix="mvc" />
         </controls>
       </pages>
     </system.web>
   
     <system.webServer>
       <validation validateIntegratedModeConfiguration="false"/>
       <handlers>
         <remove name="BlockViewHandler"/>
         <add name="BlockViewHandler" path="*" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler"/>
       </handlers>
     </system.webServer>
   </configuration>

   Можно убедиться, что такой же web.config есть в любом проекте ASP.NET MVC. По большому счету, он содержит разного рода затычки.

    
8. Tada! Конфигурационный гемор окончен. Можно делать контроллеры и вьюхи почти так же, как и в MVC web application, сделанном по шаблону. Конечно, есть определенные неудобства. Например, нету удобных диалогов Add Controller и Add View. Я с этим готов мириться - я быстро печатаю.

Отдельные вопросы - это куда класть контроллеры и модели. Я сторонник тонких контроллеров и толстых моделей (не поймите неправильно, речь идет о Domain Driven Design). Поэтому модель я бы выносил в отдельную сборку с красивым названием вроде MyMegaSite.Domain. А контроллеры либо тоже в отдельную сборку (но это только для фанатов тестирования всего на свете), либо банально в App_Code - они же тонкие.

В заключение, должен отметить, что в ASP.NET MVC Web Application классические aspx-страницы можно использовать без каких-либо дополнительных телодвижений. Цель статьи - рассказать, как пользоваться MVC в проектах типа Web Site. Если вам нравятся Web Applications, то вы счастливый человек - у вас все out of the box.

Говорят, что термин ActiveRecord придумал вездесущий Фаулер. Этот паттерн используется в Ruby on Rails и в других MVC-каркасах. Подробности можно поискать в гугле.

Castle Project предлагает на безвозмездной основе реализацию ActiveRecord, которая вызвала у меня восторг.

Чтобы попытаться придти в такой же восторг, попробуйте такое:

1. Скачайте ActiveRecord и распакуйте куда вам удобно
2. Создайте Console Application в VS 2008 и добавьте ссылки на сборки:

   Castle.ActiveRecord
   Castle.ActiveRecord.Linq
   Castle.Core
   NHibernate
   NHibernate.ByteCode.Castle
   NHibernate.Linq
   System.Data.SQLite

3. В Program.cs поместите такой код:

// A domain object:

[ActiveRecord]
public class Developer : ActiveRecordLinqBase<Developer> {

    [PrimaryKey]
    public int ID { get; private set; }

    [Property]
    public string Name { get; set; }

    [Property]
    public double CoffePerDay { get; set; }

}

// An app:

class Program {
    static void Main(string[] args) {

        // Configuring NHibernate
        // I wish Fluent NHibernate worked with ActiveRecord
        // But unfortunately in general it doesn't:
        // http://stackoverflow.com/questions/1915454/using-castle-activerecord-with-fluent-nhibernate/1918929#1918929

        var props = new Dictionary<string, string>() {
            { "connection.driver_class", typeof(NHibernate.Driver.SQLite20Driver).AssemblyQualifiedName },
            { "dialect", typeof(NHibernate.Dialect.SQLiteDialect).AssemblyQualifiedName },
            { "connection.provider", typeof(NHibernate.Connection.DriverConnectionProvider).AssemblyQualifiedName },
            { "connection.connection_string", "Data Source=c:/test.db" },
            { "proxyfactory.factory_class", typeof(NHibernate.ByteCode.Castle.ProxyFactoryFactory).AssemblyQualifiedName },
            { "show_sql", "true"}
        };

        // Initializing ActiveRecord

        var source = new InPlaceConfigurationSource();
        source.Add(typeof(ActiveRecordBase), props);
        ActiveRecordStarter.Initialize(Assembly.GetExecutingAssembly(), source);
        ActiveRecordStarter.UpdateSchema();

        // Application logic:

        if(Developer.Queryable.Count() < 1) {
            using(new SessionScope()) {
                new Developer() { Name = "Lexa", CoffePerDay = 0.1 }.Create();
                new Developer() { Name = "SergeS", CoffePerDay = 1.5 }.Create();
                new Developer() { Name = "Ramon", CoffePerDay = 0 }.Create();
                new Developer() { Name = "Beresta", CoffePerDay = 1 }.Create();
            }
        }

        var report = from i in Developer.Queryable
                     orderby i.CoffePerDay
                     where i.CoffePerDay > 0
                     select new { Name = i.Name };

        foreach(var item in report)
            Console.WriteLine(item);

        Console.ReadKey();
    }
}

После первого запуска в консоль будет выведено:

NHibernate: SELECT count(*) as y0_ FROM Developer this_
NHibernate: INSERT INTO Developer (Name, CoffePerDay) VALUES (@p0, @p1); select last_insert_rowid();@p0 = 'Lexa', @p1 = 0,1
NHibernate: INSERT INTO Developer (Name, CoffePerDay) VALUES (@p0, @p1); select last_insert_rowid();@p0 = 'SergeS', @p1 = 1,5
NHibernate: INSERT INTO Developer (Name, CoffePerDay) VALUES (@p0, @p1); select last_insert_rowid();@p0 = 'Ramon', @p1 = 0
NHibernate: INSERT INTO Developer (Name, CoffePerDay) VALUES (@p0, @p1); select last_insert_rowid();@p0 = 'Beresta', @p1 = 1
NHibernate: SELECT this_.Name as y0_ FROM Developer this_ WHERE this_.CoffePerDay > @p0 ORDER BY this_.CoffePerDay asc;@p0 = 0
{ Name = Lexa }
{ Name = Beresta }
{ Name = SergeS }

Выводится это потому, что в настройках присутствовал параметр show_sql.

Видно, что:

• Проектирование идет от объектов
• Работа ведется с объектами
• Не нужно никаких маппингов
• Для хранения можно использовать любую базу из тех, что поддерживает NHibernate
• LINQ работает!

Wow I like it.

Many-to-many (сообщает нам капитан) - это когда есть два объекта/факта/сущности, и при этом первый знает о нескольких других, а каждый другой - о нескольких первых.

Сразу несколько примеров из окружающего мира:

Первый пример я всегда привожу в пример, потому что он был для меня исторически первым. Он описывает дискографию артиста, который выпустил кроме сольников много сборников, и таким образом одна песня может встречаться на двух или трех пластинках.

Второй пример избит чуть меньше чем hello world. Есть товары, есть заказы, и заказ состоит из списка товаров.

Третий пример из области контроля доступа. Пользователям назначаются роли, чтобы дать разные полномочия в какой-то системе (например на сайте).

Все три примера представлены в виде ER-диаграмм, на которых как известно зависимость многие-ко-многим нельзя сделать, не вводя дополнительной сущности (которую еще называют junction table). Дополнительная сущность находится по центру и пока никак не названа.

В то же время в мире объектов many-to-many реализуется легко - каждый из объектов содержит в себе коллекцию объектов-партнеров:

Так выглядит первый пример с точки зрения объектной модели. Заказ имеет вполне естественную коллекцию товаров. А у товара есть не очень естественная коллекция заказов, в которых он встречается.

Но с такой двусторонней связью работать не так уж и приятно - при добавлении товара в коллекцию к заказу надо позаботиться о том, чтобы заказ попал в коллекцию к товару, а тут несложно и stack overflow схлопотать. С двусторонними связями вообще работать неудобно, а с many-to-many в особенности, но это отдельная тема.

Еще один нюанс заключается в том, что часто связь нагружена подробностями. Например, в случае песен и пластинок имеет значение порядок композиции в треклисте. Товары в заказе также упорядочены. А привязанная к пользователю роль может иметь дату истечения действия или даже критический для системы атрибут - разрешение это или запрет.

Свою мысль я веду к тому, что связующие сущности не надо прятать. Им почти всегда можно придумать красивые названия. В первом моем примере, ее можно назвать Позиция Треклиста, во втором примере - Позиция Накладной, в третьем - Правило Доступа.

У этого есть и другие преимущества. Облегчается OR-mapping, потому что дырка между миром таблиц и миром объектов исчезает. Упрощается создание CRUD-интерфейсов: чтобы показать накладную, надо просто отфильтровать все Позиции Накладной по определенному заказу.

Прошу любить и жаловать:
http://code.google.com/p/sharp-view-engine/

Это View Engine, в котором вся вьюха пишется на языке C# с помощью using-блоков

Зачем?

Чтобы обеспечить их повторное использование. К примеру, в бытность мою PHP-шником я имел небольшой проект, который генерировал добротную CRUD-админку по xml-описанию. И я просто ссылался через svn:externals на нее в каждом моем проекте.

В ASP.NET MVC было бы правильнее добавлять ссылку на скомпилированную DLL, нежели на файлы и папки.

Какие трудности?

Оказалось, что в ASP.NET MVC 2 это сделать не так-то просто. Если с контроллерами проблем не возникает, ибо они обычные классы, то с views все сильно сложнее.

В preview-релизах у них была затея под названием Area Subprojects (ахтунг, ссылка на хабр!), но в релизе они ее свели на нет, оставив только Areas в пределах одного проекта. Позор и срам!

Интернеты предлагают разные решения: регистацию своего VirtualPathProvider-а, который не работает в Medium Trust, написание наследника ViewResult, который будет выдирать aspx-файлы из embedded ресурсов и компилировать их на лету (каждый раз?)

Что первый, что второй вариант выглядят мерзко.

Я буду использовать Spark View Engine

• Он имеет более приятный синтаксис, чем месиво из процентных ASP-тегов
• Он имеет встроенную функциональность по загрузке вьюх из embedded-ресурсов
• Он позволяет полностью избавиться от WebForms в ASP.NET MVC

Говорят, что в нем даже работает intellisense, но не могу это подтвердить, потому что у меня под рукой только Visual Web Developer 2008, который не допускает плагинов. Справедливости ради, надо заметить, что от aspx и ascx файлов, помещенных в class library, тоже никакого вменяемого intellisense не дождешься. Прямо какое-то “use your favourite text editor” получается…

Демонстрация по шагам

Для начала, убедитесь, что у вас установлен ASP.NET MVC 2. Установить его легче всего через Web platform installer.

Теперь запустите студию 2008. Создайте проект “ASP.NET MVC 2 Empty Web Application”. Убедитесь, что создаете C#-проект (а то я постоянно это упускаю из внимания и создаю проекты на козлином бейсике). Проект назовите TestProject.Main.

Добавьте в solution еще один проект (File | Add | New Project) типа Class Library под названием TestProject.Part. В него добавьте ссылку на System.Web.Mvc. А на него добавьте ссылку в TestProject.Main. Надеюсь, вы еще не запутались.

Скачайте Spark. Это надо сделать в разделе Downloads на http://sparkviewengine.codeplex.com/.

В проект TestProject.Main добавьте ссылки на Spark.dll и Spark.Web.Mvc.dll.

В Global.asax в метод Application_Start надо прописать минимальную конфигурацию спарка:

var settings = new SparkSettings();
ViewEngines.Engines.Add(new SparkViewFactory(settings));

После этого в качестве вьюх будут находиться не только *.aspx и *.ascx, но и *.spark.

Итак, подготовка закончена. Начнем добавлять контроллеры и вьюхи в TestProject.Part. Создайте в проекте папку Controllers, а в ней класс TestController, унаследованный от Controller. Напишите один action-метод TestAction:

namespace TestProject.Part.Controllers {

    public class TestController : Controller {

        public ActionResult TestAction() {
            return View();
        }

    }

}

Теперь в Global.asax в методе RegisterRoutes зарегистрируем маршрут, который будет направлять посетителей на этот контроллер:

public static void RegisterRoutes(RouteCollection routes) {
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "EdrenRoute",
        "edren",
        new { controller = "Test", action = "TestAction" },
        new[] { "TestProject.Part.Controllers" }
    );

}

Этот код значит, что по запросу edren управление будет передано методу TestAction класса TestController, который будет искаться в пространстве имен TestProject.Part.Controllers.

Не забудьте стереть или закомментировать Default route! Иначе он будет конфликтовать с нашим.

Теперь можно запустить проект TestProject.Main, перейти на адрес http://localhost:NNNN/edren и получить ошибку “The view ‘TestAction’ or its master was not found.”

Подобрались вплотную к развязке. В проект TestProject.Part добавляем файл Views/Test/TestAction.spark. Вообще, студия про spark-файлы ничего не знает, поэтому можно добавить xml и поменять ему расширение. Файлу надо обязательно задать Build Action в Embedded Resource. Внутрь напишите:

<h1>Hello, it's ${DateTime.Now}</h1>

А в Global.asax осталось добавить несколько строк, чтобы Spark искал вьюхи в нужном нам месте:

var settings = new SparkSettings();

settings.AddNamespace("System");
settings.AddViewFolder(ViewFolderType.EmbeddedResource, new Dictionary<string, string>()
{
    { "assembly", "TestProject.Part" },
    { "resourcePath", "TestProject.Part.Views" }
});

Видно, что я поведал спарку о том, что хочу использовать в шаблонах пространство имен System (чтобы DateTime.Now сумело скомпилироваться) и указал местоположение шаблонов - в сборке TestProject.Part по пути TestProject.Part.Views.

Все! Теперь, если запустить страницу, которая раньше ругалась на отсутствие вьюхи, мы увидим приветствие и узнаем, сколько сейчас времени. А узнав, сколько сейчас времени, решим для себя, что на сегодня хватит высоких материй

• В ASP.NET MVC не надо запускать консольных тулзов и править конфиги на языке YAML в “вашем любимом текстовом редакторе”
   
• Для ASP.NET MVC есть отличная среда разработки под названием Visual Studio (которая даже бывает бесплатной, в Express-версии)
   
• Из предыдущего пункта вытекает, что у вас будет хороший отладчик и запускалка тестов вроде TestDriven.NET, а может быть даже CodeRush!
   
• В ASP.NET MVC вы будете писать код на C#, у вас будет на вооружении LINQ и весь .NET
   

Звучит убедительно? Или может быть вам больше нравится стиль разработки, показанный в этом скринкасте?

Как обычно, предлагаю для скачивания во всех возможных форматах:

• Таблатура в формате Guitar Pro 5
• Ноты в виде PDF файла
• MIDI

Если вы оказались в сложной ситуации - если у вас нет Guitar Pro, PDF не открывается, а от звука MIDI вы впадаете в уныние, то можете просто послушать как это примерно должно звучать.

Переложение я делал под себя. То есть, мне более-менее удобно это играть. Если кому-то еще пригодится, я буду рад.