Альтернативный MVC Framework на ASP.NET: FubuMVC

Введение

Почему же альтернативный? Всё просто, данный framework пишется силами выдающихся участников ALT.NET community, а именно:

Jeremy Miller, Chad Myers, Mark Nijhof, Ryan Kelley, и Joshua Flanagan.

FubuMVC не имеет никакого отношения к ASP.NET MVC Framework, кроме того, что так же построен поверх ASP.NET и реализует паттерн Front-Controller. Название FubuMVC строится из акронима “For us by us” и аббривеатуры MVC (кто ещё не знает, что это значит Model-View-Controller ?). Проект был инициирован по причине недовольства вышеперечисленных личностей архитектурными решениями, принятыми в ASP.NET MVC. Сказать, по правде, по прошествии года, после старта проекта, он не утратил своей элегантности и простоты в подходах.

FubuMVC вносит несколько непривычное понимание Controller’а. Теперь это не просто некоторый класс, теперь это больше логическая связность некоторых методов. Это раскрывает более широкие возможности для настройки специфичного поведения Controller’а, к примеру, обработки ошибок, реализации правил кэширования, определения типа возвращаемых значений. К тому же возможность динамического объединения вызовов Action’ов уже является удобным механизмом к расширению. Далее мы более подробно поговорим об особенностях этой реализации в FubuMVC.

В качестве View Engine (в данном случае является лишь определением и не имеет отношения к ASP.NET MVC View Engine) используется механизм рендринга WebForms (проще говоря FubuPage, которая является View в FubuMVC, наследует от System.Web.UI.Page), но имеется возможность в подключении всех существующих в ASP.NET MVC ViewEngine’ов, примером тому может быть реализация SparkViewEngine.

Конечно же уместным будет вопрос, а зачем же нужен “другой” MVC Framework, с меньшим количеством участников проекта, с меньшим вниманием со стороны разработчиков, с меньшим количеством тестеров и прочими атрибутами mainstream проектов.

В основу проекта FubuMVC его создатели заложили больше возможностей для кастомизации проекта под прикладные нужды, а так же конвенциям (соглашениям) относительно настройки и расширяемости. Причём конвенции должны покрывать основные и типичные нужды приложения, коих в разработки решений достаточно большое количество. Какие-либо дополнительные разработки будут инициировать собой появление дополнительных модулей.

ScreencastsАналогичные конвенции (соглашения) существую в известном всем MVC Framework на Ruby: Ruby On Rails. На своей практике разработки под Ruby On Rails я неоднократно убеждался, что данные конвенции действительно позволяют снизить сложность и количество написанного кода. Примером тому может служить ORM Active Record с его соглашениями касательно преобразования объектов в таблицы реляционной базы данных, а так же соглашение, относительно хранения конфигурации в формате YAML.

Официальный сайт проекта: http://fubumvc.com/

FubuMVC на GitHub: http://github.com/darthfubumvc/fubumvc

Первое погружение

Начнём с конвенций именования и структуры проекта. Вся работа с настройкой приложения FubuMVC ведётся через некоторый DSL, стиль конфигурирования очень близок к работе с FluentNhibernate.

public class HelloWorldFubuRegistry : FubuRegistry
{
    public HelloWorldFubuRegistry()
    {
        IncludeDiagnostics(true);

        Applies.ToThisAssembly();

        Actions
            .IncludeTypesNamed(x => x.EndsWith("Controller"));

        Routes
            .IgnoreControllerNamespaceEntirely()
            .ConstrainToHttpMethod(action => action.Method.Name.EndsWith("Command"), "POST")
            .ConstrainToHttpMethod(action => action.Method.Name.StartsWith("Query"), "GET");

        Views
            .TryToAttach(x=>
            {
                x.to_spark_view_by_action_namespace_and_name(GetType().Namespace);
                x.by_ViewModel_and_Namespace_and_MethodName();
                x.by_ViewModel_and_Namespace();
                x.by_ViewModel();
            });

        Output.ToJson.WhenCallMatches(action => action.Returns<AjaxResponse>());

        HomeIs<HomeInputModel>();
    }
}

Исходя из данной конфигурации IoC-container’а нетрудно догадаться о следующем:

  • Все классы, оканчивающиеся на “Controller” будут зарегистрированны в качестве Controller
  • Все запросы, оканчивающиеся на “Command” должны будут приниматься POST’ом, а начинающиеся на “Query” GET’ом
  • Все View будут заполняться соответствующими по именованию ViewModel
  • Весь вывод, возвращающий тип AjaxResponse будет серилизоваться в JSON

В качестве IoC-container’а в FubuMVC выбран StructureMap. Выбор не случаен, т.к. фактически StructureMap является старейшим IoC/DI-container’ом. Начало разработки датировано июнем 2004ого года и велось Jeremy D. Miller, так же и участником проекта FubuMVC.

Второе погружение

Давайте рассмотрим несколько примеров приложений на FubuMVC

Первое из них http://github.com/DarthFubuMVC/fubumvc-examples/tree/master/src/Actions/ControllerActionStyle/

Начнём, с того, что проверим его работоспособность:

image

В namespace’е SimpleWebsite.Core определена наша модель предметной области, а именно Movies, работе с которыми и просвещенно приложение.

В SimpleWebsite.Controllers определен единственный Controller и View, работу которых мы и видим на рисунке выше.

Давайте разберемся с MoviesController. Судя по его конструктору нетрудно догадаться, что DependencyInjection мы получаем out-of-box без каких-либо переопределений Controller Factory:


private readonly IRepository _repository;

public MoviesController(IRepository repository)
{
    _repository = repository;
}

Метод List() является “списочным” и предоставляет нам доступ к ViewModel


public ListMoviesViewModel List()
{
    return new ListMoviesViewModel {Movies = _repository.Query<Movie>()};
}

Стоит обратить внимание на конвенцию именования в данном случае. Под ViewModel (читается так же как PresentationModel) понимается адаптированная для представления модель, что подчеркивает SoC в реализации FubuMVC. View в данном случае будет строго типизировано на  этот тип:

 public class List : FubuPage&lt;ListMoviesViewModel&gt;   <br />{}

Метод Add() попадает под правило обработки AjaxResponse, следовательно вернется на страницу в виде JSON, где будет радужно встречен jQuery обработчиком.

image

Аналогичная ситуация с методом Remove().

Стоит обратить внимание на конвенцию именования принимаемых данными методами типов:

AddMovieInput, RemoveMovieInput

Наименования данных классов указывают на направление данных, т.е. их ввод с запросом. С помощью этих типов на View мы определяем Url для обработки соответствующих Action’ов Controller’а:

<%= Get<IUrlRegistry>().UrlFor(new AddMovieInput()) %>

FubuMVC реализует 3 модели обработки запросов:

  1. Controller / Action Привычный для ASP.NET MVC Framework способ. Определяется некоторый тип — Controller, который содержит в себе соответствующие методы — Action’ы. Данный пример был рассмотрен выше.
  2. Controller-less Actions (HandlerStyle) Данный способ подразумевает под собой “обезличенные” Action’ы. т.е. без привязки к какому-либо Controller’у. Правила нахождения Action’ов описываются Policy, которые можно описывать и добавлять в коде.
  3. REST-like (EndPointStyle) Этот способ близок к предыдущему, однако, в отличии от него реализует не только метод Execute, а все методы, необходимые для REST взаимодействия, каждый метод Get(), Post(), Put(), Head() в дальнейшем будет соответствовать типу HTTP запроса:
var httpVerbs = new HashSet<string>(StringComparer.InvariantCultureIgnoreCase)
    {"GET", "POST", "PUT", "HEAD"};

Погружаемся далее

Как вы уже догадались, FubuMVC славится своими возможностями для расширения. Предлагаю ознакомиться с ещё одним примером: http://github.com/DarthFubuMVC/fubumvc-examples/tree/7c4b2165aedb6754a01538aee956e29d4060654c/src/Outputs/VaryByAcceptHeader

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

Этот пример практически ни чем не отличается от рассматриваемого, раннее, за тем лишь исключением, что в классе

VariableOutputConvention : IConfigurationAction

мы регистрируем интересующие нас возвращаемые типы, а так же указываем дополнительный Behavior для рендринга страницы:

RenderVariableOutput : BasicBehavior

После чего достаточно только заполнить интересные вам Movies http://localhost:59187/movies/list и попросить вернуть их в JSON http://localhost:59187/movies/list?renderformat=json или в XML http://localhost:59187/movies/list?renderformat=xml

Данный пример наглядно иллюстрирует точки расширения FubuMVC для любых нужд.

Диагностика

По адресу http://localhost:59187/_fubu вас будет ждать небольшой сюрприз, а именно – диагностическая утилита для FubuMVC.image

C её помощью вы сможете просматривать все зарегистрированные в вашем приложении

  • Chains – цепочки поведения, так называются логические связи между маршрутами и Action’ами. О цепочках можно посмотреть все обертки и возвращаемые значения.
  • Routes – показывает все зарегистрированные маршруты, и связанные с ними Action’ы, тип выводимых данных и цепочки поведения.
  • Actions – зарегестрированные в приложении Action’ы, их маршруты и возвращаемые значения
  • Inputs – возможные типы и способы ввода в вашем приложении со стороны запросов

Заключение

При первом и поверхностном знакомстве проект FubuMVC не показался мне чем-то выдающимся. Однако в последнее время мой интерес к нему постоянно растёт. Я считаю, что FubuMVC является более удобным и гибким инструментом, по сравнению с ASP.NET MVC. Однако это ещё не значит, что я уже готов доверить данному проекту свои коммерческие проекты. Тот факт, что сообщество всё же поддерживает многообразие качественных решений для создания приложений на ASP.NET, может только радовать.

Материалы

FubuMVC Contrib http://code.google.com/p/fubumvc-contrib/

Front Controller http://msdn.microsoft.com/en-us/library/ms978723.aspx

FubuMVC — Front Controller style framework  http://blog.fohjin.com/blog/2009/2/21/FubuMVC_Front_Controller_style_framework

FubuMVC Google Group http://groups.google.com/group/fubumvc-devel?pli=1

Ещё один MVC Framework на ASP.NET OpenRasta http://trac.caffeine-it.com/openrasta

Соглашение относительно настройки http://msdn.microsoft.com/ru-ru/magazine/dd419655.aspx


SubSonic: магия и ORM

О чём это?

На днях передо мной стояла задача создания прототипа веб-приложения с определенным набором функций, в том числе, подразумевающих работу с данными. Набор инструментов я подобрал следующий:

  • ASP.NET MVC
  • SQLite

Набросав первое приближение модели предметной области, я озаботился её сохраняемостью и решил заняться выбором ORM:

  • LINQ to SQL насколько известно умеет работать только с Microsoft SQL Server
  • Entity Framework ещё не готов в пригодной версии
  • DBLinq вроде бы прекрасно работает со всеми известными RDBMS, однако отсутствие его популярности и низкая версия немного меня оттолкнули
  • О SubSonic я слышал краем уха, однако так и не имел тесного знакомства, на нём и решил остановится, фреймворк имеет в багаже уже 3юю версию, а так же известного создателя (Rob Conery)

Чем же хорош SubSonic?

SubSonic

Очень заинтересовали 5 минутные ролики о SubSonic:

http://subsonicproject.com/docs/The_5_Minute_Demo

http://subsonicproject.com/docs/Simple_Repo_5_Minute_Demo

Кстати SubSonic помимо того, что является ORM, так же предоставляет слой доступа к данным.

Итак в 3ей версии SubSonic мы имеем 2 сценария работы:

  • ActiveRecord – фактически повторяет классический для Ruby On Rails подход, в котором модель является моделью данных, т.е. знает о способах своей сохраняемости. Данный подход в случае SubSonic полезен в построении дата-ориентированных решений, вам достаточно просто сохранить в T4 шаблоне имя строки подключения к имеющейся у вас базе данных, остальное SubSonic сделает сам (генерирует соответствующие данным .NET-типы в вашем приложении)
  • SimpleRepository – более привычный для меня подход, подразумевает под собой абстракцию хранения данных под некоторым классом-коллекцией объектов.

Реализация обоих сценариев прозрачна с точки зрения подхода и реализует соответствующие паттерны PoEAA:

Как же я воспользовался SubSonic в своём приложении?

Я о определил интерфейс репозитория:

  public interface IRepository<T>
  {
    void Add(T entity);
    T FetchById(long id);
    IEnumerable<T> FetchAll(Expression<Func<T, bool>> predicate);
    IEnumerable<T> FetchAll();
    void Update(T entity);
    void Remove(T entity);
  }

Имплементация его имела следующий вид:

  public class EntityRepository : Domain.IRepository<Entity>
  {
    readonly IRepository _db;

    public ComputersRepository()
    {
      _db = SimpleRepositoryFactory.Create();
    }

    public void Add(Entity entity)
    {
      _db.Add(entity);
    }

    public Computer FetchById(long id)
    {
      return _db.Single<Entity>(x => x.Id == id);
    }

    public IEnumerable<Computer> FetchAll(Expression<Func<Entity, bool>> predicate)
    {
      return _db.Find(predicate);
    }

    public IEnumerable<Computer> FetchAll()
    {
      return _db.All<Entity>();
    }

    public void Update(Entity entity)
    {
      _db.Update(entity);
    }

    public void Remove(Entity entity)
    {
      _db.Delete<Entity>(entity.Id);
    }
  }

Как вы успели заметить производством SimpleRepository занимается фабрика:

  public class SimpleRepositoryFactory
  {
    public static SimpleRepository Create()
    {
      IDataProvider dataProvider = ProviderFactory.GetProvider(ConnectionString, "System.Data.SQLite");
      return new SimpleRepository(dataProvider, SimpleRepositoryOptions.RunMigrations);
    }

    protected static string ConnectionString
    {
      get
      {
        return "Data Source=data.db;Version=3;";
      }
    }
  }

Кстати, это всё, что нам понадобится, для работы со слоем сохранения. Давайте теперь разберёмся, что же именно будет делать SubSonic. Фактически он возмёт на себя все задачи по генерации базы данных и всех таблиц. Так же он предоставит все механизмы для доступа по-средствам Linq. Однако стоит иметь ввиду, что SubSonic SimpleRepository не умеет работать со сложными типами и ссылками на другие типы (однако это проблема решается благодаря Join’ам в запросах)

Интересной возможностью является возможность работы с «пакетами» данных:

IEnumerable<Post> posts=GetABunchOfNewPosts();
repo.AddMany(posts);
 
//update a post
repo.Update(post);
 
//update a bunch of posts in a transaction
IEnumerable<Post> posts=GetABunchOfNewPosts();
repo.UpdateMany(posts);
 
//delete a post
repo.Delete<Post>(key);
 
//delete a lot of posts
repo. DeleteMany <Post>(x=>x.Title.StartsWith("M"));
 
//delete posts using a transaction
IEnumerable<Post> posts=GetABunchOfNewPosts();
repo.DeleteMany(posts);

Проблема с пейджингом так же решена из коробочки:

//a PagedList of posts - using 10 per page
var posts=repo.GetPaged<Post>(0,10);
//sort by title
var posts=repo.GetPaged<Post>("Title",0,10);

Диагноз

Рекомендую SubSonic как лучшее решения доступа к данным для прототипирования


Курс молодого бойца ASP.NET MVC

Недавно попросили приготовить задание/программу подготовки работы на ASP.NET MVC для обучения “с нуля”. Может кому-нибудь пригодится.

Подготавливаем рабочую среду:

1. Поставить Visual Studio 2008 Express Edition (Web Developer) SP1

http://www.microsoft.com/exPress/download/

2. Поставить SQL Server 2008 Express Edition

http://www.microsoft.com/exPress/download/

3. Поставить ASP.NET MVC 1.0

http://www.asp.net/mvc/download/

Про MVC здесь

http://ru.wikipedia.org/wiki/Model-View-Controller

http://msdn.microsoft.com/en-us/library/ms978748.aspx

http://martinfowler.com/eaaDev/uiArchs.html

4. Поставит платформу для модульного тестирования MbUnit 3 и платформу Galio

http://www.gallio.org/Default.aspx

Про TDD здесь:

http://codebetter.com/blogs/darrell.norton/articles/50337.aspx

http://martinfowler.com/articles/mocksArentStubs.html

Теория:

1. Запустить Visual Studio и создать ASP.NET MVC Web Application

2. Разобраться со структурой проекта

3. Четко понимать отношения между представлениями (Views) и контроллерами (Controllers).

4. Понимать принципы маршрутизации приложения (посмотреть в Global.asax)

5. Суметь объяснить назначение Site.Master

6. Понимать и уметь работать с PartialView (ascx)

7. Понимать взаимодействие с моделью данных (DataModel), организовать преобразование записей из SQL Server в сущности предметной области. (Необязательно c помощью linq2sql, либо самостоятельно)

Посмотреть про TDD и MbUnit http://blog.benhall.me.uk/2007/12/screencast-getting-started-with-mbunit.html

Хорошие скринкасты на http://www.asp.net/mvc/learn/

Здесь на русском: http://www.techdays.ru/Search.aspx?Quick=MVC

Посмотреть что умеет Dynamic Data http://www.techdays.ru/videos/1064.html — это примерно то, что нужно будет сделать самому

Задание: Создать простейший веб-блог.

1. Создать представления списочного, детального просмотра.

Попробовать один и плагинов http://anton.shevchuk.name/javascript/jquery-datagrid-plugins/.

Здесь есть неплохое руководство по взаимодействию http://www.trirand.com/blog/?s=AJAX

2. Предоставить возможность редактирования записей

3. Создать RSS-ленту для списка записей в блоге

4. Организовать покрытие unit-тестами контроллеров и модели данных при разработке


Языки предметной области Domain-Specific Languages (DSL)

Что это?

Это некоторая форма компьютерных языков, разрабатываемых для специфичной предметной области. Это то, что позволяет вам (разработчикам ПО) лучше взаимодействовать с носителями “доменных знаний”. А так же позволяет более лаконично оформлять бизнес-логику. Это то, что представляет собой, к примеру, SQL, Linq, многое из синтаксиса Ruby On Rails.

Зачем мне это?

Если вы согласны с утверждением: “Языки общего назначения порой слишком красноречивы”, вы разрабатываете на .NET, либо сильно интересуетесь программированием, то наш доклад будет вам интересен.

Что я узнаю?

Ответы на следующие вопросы:

  • Что такое DSL?
  • Откуда это понятие пришло к нам?
  • Какие бывают DSL?
  • Какие “языки общего употребления (GPL)”  предоставляют возможности построения DSL? Какие из них есть на .NET?
  • Почему я должен использовать DSL? Какие плюсы от этого?
  • Какие шаблоны используются при построении DSL?
  • А можно увидеть примеры?

Материалы нашего выступления

Слайды презентации

Building DSLs on CLR and DLR (.NET)

Видео:

http://video.yandex.ru/users/thecoffee/collection/1/

Видео в более пригодном к рассматриванию надписей на доске качестве можно слить по ссылкам ниже:

http://narod.ru/disk/9278634000/01.wmv.html

http://narod.ru/disk/9279885000/02.wmv.html

Все рассмотренные примеры доступны здесь:

http://spbalt.net/Content/Baum_Moiseev_DSL.zip


Учимся проектировать на основе предметной области (DDD: Domain Driven Design)

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

2. Так почему же DDD?

Есть несколько шаблонов реализации предметной области (Domain Logic) или бизнес-логики (Business Logic):

1) Table Module – представляет собой объект, в единственном экземпляре, обрабатывающий бизнес логику для всех записей в таблице базы данных, либо представления.

2) Transaction Script – организует взаимодействие с бизнес-логикой посредствам процедур, принимающих запросы с уровня представления.

3) Domain Model – непосредственно, объектная модель предметной области, включающая в себя как поведение, так и данные.

Эти шаблоны описаны более подробно Мартином Фаулером, в его книге “Архитектура корпоративных программных приложений. Шаблоны корпоративных приложений(Patterns of Enterprise Application Architecture (P of EAA)). В данной книге он показывает, что первые два шаблона более привлекательны в начале работы с предметной областью, однако так же обращает внимание, что при наращивании сложности логики предметной области стоит больше внимания уделять сопровождению инфраструктуры, используя первые два подхода, это время можно уменьшить, если обратиться в своём решении к третьему из вышеперечисленных шаблонов, так называемой “Модели предметной области”.

На основе этого сделаем небольшой вывод о том, что данный шаблон (“Модель предметной области”) лучше всего подойдёт, к примеру, для такой непростой области, как финансовый рынок. Большинство, создаваемого в наши дни программного обеспечения предназначено для различных нужд бизнеса, следовательно какие-то абстрактные, обобщенные решения находят своё место на рынке (с довольно таки высокой конкуренцией) всё реже и реже. К чему я пишу про всё это? Потому что DDD – это не только качественное проектирование, но так же и показательный пример того, как следует выделить предметную область в программном обеспечении, для того, чтобы проще преодолевать сложности, частые изменения, проблемы коммуникации и прочие недуги предметной области, вместо того чтобы разрабатывать уродливую, сложную для понимания систему, в которой любое изменение или исправление способно обрушить на вас лавину всё новых и новых дефектов.

DDD ни в коем случае не отрицает наследия практик разработки, таких как:

DDD лишь дополняет их. Поиск подходящей модели и абстракций в сложных сценариях требует значительных знаний в сфере объектно-ориентированного подхода, и достаточного опыта применения различных принципов, шаблонов и практик, а не просто DDD, как может показаться.

3. С чего можно начать?

Если мой “нудный PR”  проектирования на основе предметной области (DDD) вас до сих пор не утомил, то думаю нам стоит продолжить, если же иначе, то посмотрите хотя бы ссылки на материалы.

Первой книгой пролившей свет на DDD для широкой публики была так называемая “Большая синяя книга” (мем. BBB: Big Blue Book): Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans (на русский язык пока не переведена).

Книга довольна подробно рассказывает о том, что из себя представляет DDD, и все связанные аспекты, такие как: язык предметной области, шаблоны, практики проектирования, рефакторинг, моделирование, как сделать разработку гибкой и многое другое. Но даже если вы ознакомитесь со всеми вопросами, поднятыми в книге (что является не совсем простым занятием), вы обратите внимание, что вопросы рассматриваются только с теоретической точки зрения, оставляя весь простор для практики (книга не привязана к конкретной платформе разработки). Для большинства из нас чтение чистой теории, без подкрепления практическими примерами не нравится, в связи с этим можно обратить своё внимание на сокращенную (и свободную для доступа) версию этой книги, подготовленную порталом InfoQ: Domain Driven Design Quickly.

Есть так же несколько хороших презентаций Эрика Ивенса (Eric Evans), с которых можно начать:

1) DDD: putting the model to work

2) Eric Evans on DDD: Strategic Design

На портале InfoQ можно найти множество других презентаций, статей и интервью, посвященных DDD.

Итак, с теоретической частью мы разобрались, где же можно найти примеры практического применения DDD? Отличной книгой для этого является .NET Domain-Driven Design with C#, Problem – Design – Solution написанная Tim McCarthy. 

В этой книге вы наёдете практические примеры:

1) Как проходит процесс проектирования и разработки, от определения требований, до написания кода

2) Как организовывать архитектурные слои в своих решениях

3) Как применять шаблоны и практики DDD

4) Как построить небольшой каркас для DDD

5) Как изолировать домен предметной области от модели

6) Современные паттерны представления данных и взаимодействия с ними (Model-View-ViewModel) в такой среде как WPF (так же применимы к Silverlight) в практики.

Эта книга – отличный практикум по DDD, содержащий очень широкий пласт идей. Начинается книга с разработки требований, а заканчивается реализацией промышленного приложения, исходные коды которого доступны на Codeplex.

Вся концепция книги построена на 3 книгах-столпах DDD:

  1. PoEAA Мартина Фаулера
  2. DDD Эрика Ивенса
  3. Applying Domain — Driven Design and Patterns by Jimmy Nilsson’s (“Применение шаблонов проектирования: проблемно-ориентированное проектирование приложений с примерами на C# и .NET” Джимми Нильссона )

В этой книге поверхностно рассмотрены все вопросы, техники и паттерны, применяемые в DDD, все примеры сопровождаются кодом, что упрощает понимание. Книга превосходная, однако русский перевод подкачал, поэтому, рекомендую прочитать оригинал.

 

 

Однако DDD – это не просто практические решения или шаблоны, это мышление и подход, и есть великое множество нюансов, которые необходимо учитывать, если вы решили следовать DDD, таких как: фокусирование на высокий приоритет отдается модели, выработка языка предметной области, контекст модели, процесс моделирования, разделение знаний, рефакторинг, стратегический дизайн и т.д…это является  основной причиной ознакомиться с книгой Эрика Ивенса, так как она даст вам более объемное и глубокое понимание философии DDD.

DDD не привязанны к конкретной технологии, однако соблюдать DDD будет не так просто, без наличия хороших средств и практик в вашем арсенале, таких как: TDD-фреймворк, ORM, возможность реализации независимости сохраняемости (Persistence Ignorance), IoC-контейнер (Inversion of Control), и возможностей AOP (Аспектно-Ориентированного Программирования), конечно не значит, что все эти инструменты нам понадобятся, однако они приблизят нас к реализации DDD на практике. Практичная ценность этих средств в том, что они позволять изолировать модель предметной области, что является ключевой целью DDD. Книга Джимми Нильссона может познакомить вас с возможностями и видами данных инструментов. Джимми так же показывает как использовать шаблоны реализации корпоративных приложений, и строить, благодаря им, цельное решение, основанное на современных инструментах и практиках.

Некоторые реализации шаблонов DDD на Ruby On Rails:

Some DDD (Domain Driven Design) Concepts implemented in Rails

4. Актуальные вопросы DDD

C DDD так же тесно связана такая тема, как DDDD: Distributed Domain Driven Design (Распределенный DDD). DDDD – это DDD в распределенных сценариях. В настоящее время существует не так много ресурсов, посвященных DDDD, в нескольких словах о DDDD: покрывает проблему реализации сообщений и DDD, разделение команд и запросов (Command Query Separation (CQS)) помогает реализовать данный подход. Грег Янг (Greg Young) сообщил, что готовит книгу, посвященную DDDD.

SOA и DDD – это ещё одна объемная тема, часто обсуждаемая Udi Dahan

5. DDD шаблоны, концепции и понятия

В промышленных приложениях DDD использует ряд шаблонов, часть которых описана в книге Эрика Ивенса, но, это не отменяет применение объектно-ориентированного подхода, включающего GoF-шаблонышаблоны Мартина Фаулера, описанные в его PoEAA, Шаблоны интеграции корпоративных приложений и т.д.…

Вот некоторые из них:

6. Примеры приложений

Найти хорошие примеры реализации DDD очень сложно, не потому что их не существует, а потому что реальная сила DDD реализуется в приложениях, используемых в довольно сложных областях, и, как правило, являющихся коммерческими проектами. Однако можно найти несколько неплохих проектов, в которых можно проследить некоторые идеи реализации шаблонов DDD.

Вот они:

1) Приложение Тима Маккарти его проект, описанный в деталях в его книге. Он описывает не только применение шаблонов, но так же акцентирует внимание в разработке модели предметной области с точки зрения DDD.

Проект так же интересен тем, что построен на .NET 3.5 и демонстрирует всю силу современного подхода связывания данных с моделью предметной области (data binding, реализация шаблона MVVM). Так же его стиль примечателен умением выделять абстракции и повторно используемый код.      

2) Следующий проект, на который следует обратить внимание – это приложение разработанное Yves Goeleven, создание данного приложения описано в его блоге (так же посвященному основным концептам DDD). Другим его приложением является DDD-каркас. Следует обратить внимание на его реализацию взаимодействия шаблонов Repository и Specification

3) Billy McCafferty разрабатывает потрясающий open source фреймворк, сфокусированный на DDD, под названием S#arp Architecture. У него есть очень хорошее описание, включающее в себя описание шаблонов и подходов, заключенных в фреймворке. Фреймворк нацелен на разработку ASP.NET MVC приложений с применением NHibernate.

4) C# Domain-Driven Design sample application ( ndddsample ), это приложение, разрабатываемое Джимми Нильссоном, демонстрирует разбиение приложения на ключевые слои с точки зрения DDD. Так же демонстрируется практическое применение шаблонов building block в предметной области перевозки грузов, описанной в его книге.

Этот проект основан на совместной работе компании Эрика Ивенса “Domain Language” и шведской консалтинговой компании “Citerus”.

Цель этого проекта:

  • Показать практическое применение использования DDD с применением .NET.
  • Использование актуальных утилит, технологий и методологий разработки в области .NET, обсуждаемых ALT.NET-коммунити.
  • Привести практические примеры реализации типовых DDD приложений.
  • Показать способ реализации DDD на конкретной платформе, что позволит без труда осуществить тоже самое на любой другой платформе.
  • Помочь в выборе реализуемых практик. Различные подходы позволят сообществу обсудить их и выбрать соответствующий для конкретной реализации.

здесь более подробная информация.

7. Ресурсы по Domain Driven Design

Официальный сайт — http://domaindrivendesign.org/

Группа обсуждений — http://tech.groups.yahoo.com/group/domaindrivendesign/ это взрослая группа, очень хороший источник идей, место для обсуждений всех видов проблем в области DDD. В ней на ваши вопросы могут ответить опытные в DDD люди, даже Эрик Ивенс :-).

Блог Jimmy Bogard’а — http://www.lostechies.com/blogs/jimmy_bogard/default.aspx

Блог Colin Jack’а — http://colinjack.blogspot.com/

Блог Greg Young’а — http://codebetter.com/blogs/gregyoung/default.aspx

Блог Casey Charlton’а — http://devlicio.us/blogs/casey/

Блог Udi Dahan’а — http://www.udidahan.com/

Введение в Domain-Driven Design — http://msdn.microsoft.com/ru-ru/magazine/dd419654.aspx

8. Заключение

Если вы заинтересованы в расширении ваших “объектно-ориентированных горизонтов” в сложных корпоративных системах и изучении новых способов разработки и проектирования, то DDD – именно то что нужно.

http://weblogs.asp.net/arturtrosin/archive/2009/02/09/domain-driven-design-learning.aspx


MonoDevelop – Разрабатываем ASP.NET MVC приложения на Mac OS X

После релиза preview ASP.NET MVC MonoDevelop addin, я решил попробовать его на Маке.

Хотя MonoDevelop 2.0 на Маке до сих пор в alpha-врсии, он получше того, что было в версии 1.0. Помимо проблем с перерисовкой GTK+ , основными проблемами в Мак-интеграции являются реализация Ctrl-Click, меню верхнего уровня и Мак шоркатов. Сделать в MonoDevelop полноценную поддержку Мака –это наша цель в MonoDevelop 2.2.

Я скачал Mono 2.4 и MonoDevelop 2.0 для маков (alpha версию), установка подобна установки аналогов в Linux, немного отличается парочкой предупреждений во время установки, но работает это безупречно!

Running an ASP.NET MVC app in MonoDevelop on the Mac

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

Оригинал

http://davidhayden.com/blog/dave/archive/2009/05/06/MonoDevelopMac.aspx

http://mjhutchinson.com/journal/2009/04/04/monodevelop_aspnet_mvc_mac

http://tirania.org/blog/archive/2009/May-05-1.html


Третья встреча Петербургской группы ALT.NET

Третья встреча Петербургской группы ALT.NET, посвященная разработке под ASP.NET MVC, пройдет в четверг, 2го Апреля в 19:00.
Встречи группы проходят по адресу Биржевая Линия дом 14, офис 409 (4й этаж) (карта).

Программа

  • 19:00 – 21:00 — ASP.NET MVC, Александр Попов (c 2006 года Microsoft MVP)

ASP.NET MVC

  1. Краткое Введение в ASP.NET MVC
  2. DDD в ASP.NET MVC
  3. SharpArchitecture
  4. Spark
  5. Patterns

Регистрация на сайте. Ждем вас!