hazzik's technoblog

Web.Requre - client script dependency framework

noreply@blogger.com (hazzik) — Sun, 09 Oct 2011 19:46:00 +0000

Что это?

Web.Require - небольшая библиотечка, для облегчения подключения скриптов в ваше Web-приложение.

Давай примеры!

<head>
    <title>@ViewBag.Title</title>
    @Html.RequireStyleSheet(
        Url.Content("~/Content/reset.css"),
        Url.Content("~/Content/Site.less"),
        Url.Content("~/Content/themes/base/minified/jquery.ui.all.min.css"))

    @Html.RequireScript(
        Url.Content("~/Scripts/jquery-1.6.4.min.js"), 
        Url.Content("~/Scripts/jquery-ui-1.8.16.min.js"))

    @Html.OutputRequiredStyleSheets()
    @Html.OutputRequiredScripts()
</head>

Что тут происходит? Все очень просто: мы подключаем три css и два js файла. Что нам дает такой подход? Почему просто нельзя подключить скрипты в лоб?

Давайте представим, что какой-то контрол, например ваш кастомный диалог или, datepicker требует для своей работы отдельного скрпта? Как быть?

Первый вариант - просто в контроле написать <script src=.../>. А если этот контрол на странице используется несколько раз?

Второй вариант - просто включить этот скрипт в <head>. А если этот скрпит очень большой и прожорливый и используется не везде?

Все очень просто: с помощью Web.Require совместим оба варианта и решим их проблемы: скрипт подгружается только один раз и только тогда, когда это необходимо. Например:

<!--DateTimePicker.cshtml-->
@Html.RequireScript(
    Url.Content("~/Scripts/jquery-1.6.4.min.js"),
    Url.Content("~/Scripts/jquery-ui-1.8.16.min.js"),
    Url.Content("~/Scripts/jquery.ui.datepicker-ru.js"),
    Url.Content("~/Scripts/DateTimePicker.js"))

В итоге DateTimePicker.js добавиться в тэг и наступит всеобщее счастье;)

Как установить?

PM> Install-Package Web.Require

P.S.

В будущем ожидаются следующие фишки:

Асинхронное подключение js
Конкатенация и минификация js и css + кэширование

P.P.S.

Пример использования можно посмотреть здесь

MvcExtensions: bootstrapping

noreply@blogger.com (hazzik) — Wed, 24 Aug 2011 11:52:00 +0000

Как я уже писал во введении, весь код, выполняющийся при старте приложения необходимо помещать в, BootstrapperTask.

Bootstrapper tasks

В MvcExtensions для размещения кода, выполняющегося при запуске приложения существует понятие Bootstrapper, которому можно назначать задачи.

Назначение задачи происходит следующим образом:

//Global.asax.cs
    public class MvcApplication : WindsorMvcApplication
    {
        public MvcApplication()
        {
            Bootstrapper.BootstrapperTasks
// задача, для регистрации контроллеров в IoC контейнер.
                .Include(); 
        }
    }

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

Регистрация маршрутов

Для регистрации маршрутов вам необходимо унаследоваться от абстрактного класса RegisterRoutesBase, и подключить задачу к bootstrapper.

public class RegisterRoutes : RegisterRoutesBase
{
    public RegisterRoutes(RouteCollection routes) : base(routes)
    {
    }

    protected override void Register()
    {
        Routes.IgnoreRoute("favicon.ico");
        Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        Routes.MapRoute("Default", 
            "{controller}/{action}/{id}", 
            new { controller = "Home", action = "Index", id = UrlParameter.Optional });
    }
}

Конфигурация фильтров

Еще одной интересной возможностью MvcExtensions является возможность добавлять фильтры (IMvcFilter) к действиям контроллеров динамически. Этот подход позволяет писать фильтры не через атрибуты, а как обычные классы, при этом появляется возможность использовать инжекцию зависимостей через конструктор. Для регистрации фильтров необходимо унаследоваться от базового абстрактного класса ConfigureFiltersBase.

Рассмотрим небольшой пример:

public class ConfigureFilters : ConfigureFiltersBase
{
    public ConfigureFilters(IFilterRegistry registry) : base(registry) { }

    protected override void Configure()
    {
        Registry.Register<ProductController, PopulateCategories, PopulateSuppliers>(c => c.Create())
                .Register<ProductController, PopulateCategories, PopulateSuppliers>(c => c.Edit(0));
    }
}

Как видно из примера, для контроллера ProductController для действий Create и Edit регистрируются два фильтра PopulateCategories и PopulateSuppliers

Регистрация ModelBinder

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

public class ConfigureModelBinders : ConfigureModelBindersBase
{
    public ConfigureModelBinders(TypeMappingRegistry<object, IModelBinder> registry) 
        : base(registry) { }

    protected override void Configure()
    {
        Registry.Register<ProductEditModel, ProductEditModelBinder>();
    }
}

Здесь вроде все понятно.

Собственные Bootstrapper tasks

Нет ничего проще, чем создать собственные задачи: необходимо просто унаследоваться от базового класса BootstrapperTask. Также задачи могут зависеть от других задач, для этого вашу задачу нужно пометить атрибутом [DependsOn]. И главное: не забудьте зарегистрировать свои задачи в бутстрапер.

[DependsOn(typeof(RegisterRoutes))]
public class ConfigureFiltersBase : BootstrapperTask
{
    protected override void Configure() 
    {
// Ваш код будет здесь
    }
}

Вместо заключения

На сегодня все. В следующей статье я планирую подробно рассмотреть конфигурацию метаданых.

MvcExtensions: введение

noreply@blogger.com (hazzik) — Sat, 20 Aug 2011 06:00:00 +0000

MvcExtensions - это библиотека расширений для ASP.NET MVC. Библиотека предоставляет пользователю мощнейший инструмент для конфигурирования метаданных для ASP.NET MVC посредством fluent-интерфейса. Второй важной особенностью библиотеки является возведение использования IoC контейнера в абсолют (Можно инжектировать данные даже в атрибуты).

С чего начать?

Для начала вам необходимо определится с IoC контейнером, который вы хотите использовать - в MvcExtensions есть адаптеры для следующих популярных IoC контейнеров: Castle.Windsor, Unity, Ninject, StructureMap. Для этого вам необходимо установить соответствующую версию адаптера через nuget: Castle.Windsor, Unity, Ninject, StructureMap.

Затем вам необходимо унаследовать класс своего приложения от базового приложения для выбранного адаптера, например, MvcExtensions.WindsorMvcApplication:

//Global.asax.cs
    public class MvcApplication : WindsorMvcApplication
    {
    	public MvcApplication()
    	{
 
    	}
    }

Инициализируем IoC контейнер

Для инициализации вашего любимого IoC контейнера вам необходимо просто реализовать соответствующий интерфейс или унаследоваться от базового класса: IWindsorInstaller, Ninject.Modules.NinjectModule, StructureMap.Configuration.DSL.Registry, Microsoft.Practices.Unity.IModule. Например для Windosor:

public class AccountInstaller : IWindsorInstaller
    {
        public void Install(IWindsorContainer container, IConfigurationStore store)
        {
            container.Register(Component.For<IAuthenticationService>().ImplementedBy<FormsAuthenticationService>().LifeStyle.Transient);
        }
    }

Полученные таким образом классы нужно положить в ваше MVC приложение в любую папку, я рекомендую в <YourMvcApplication>/Infrastructure. Необходимо запомнить, что контроллеры таким образом инициализировать не требуется!.

Регистрация контроллеров

В MvcExtensions весь код, выполняющийся при старте приложения необходимо помещать в, так называемые, BootstrapperTask. Существуют некоторые стандартные таски, такие как например регистрация контроллеров. Для того, чтобы проинструктировать MvcExtensions, что вы хотите зарегистрировать свои контроллеры, необходимо всего-лишь включить задачу RegisterControllers в последовательность задач, выполняемых при старте:

//Global.asax.cs
    public class MvcApplication : WindsorMvcApplication
    {
        public MvcApplication()
    	{
       		Bootstrapper.BootstrapperTasks
    			.Include<RegisterControllers>();
    	}
    }

После этого все контроллеры в вашем MVC приложении будут создаваться с помощью IoC контейнера.

Метаданные

MvcExtensions предлагает пользователям замену стандартному способу конфигурирования метеданных через DataAnnotations, посредством fluent-интерфейса для конфигурирования. Этот подход обладает феноменальной гибкостью и неограниченными возможностями для расширения.

Для того, чтобы использовать эту возможность в MvcExtensions необходимо также зарегистрировать ее:

//Global.asax.cs
    public class MvcApplication : WindsorMvcApplication
    {
        public MvcApplication()
    	{
       		Bootstrapper.BootstrapperTasks
    			.Include<RegisterControllers>()
     			.Include<RegisterModelMetadata>();
    	}
    }

Затем необходимо написать конфигурацию для ваших форм и моделей отображения:

public class SignUpMetadata : ModelMetadataConfiguration<SignUp>
    {
        public SignUpMetadata()
        {
            Configure(x => x.Login)
                .DisplayName("Имя пользователя")
                .Required("Необходимо указать имя пользователя");

            Configure(x => x.Email)
                .DisplayName("Адрес электронной почты")
                .Required("Необходимоуказать адрес электронной почты")
                .AsEmail();

            Configure(x => x.Password)
                .DisplayName("Пароль")
                .Required("Необходимо указать пароль")
                .MinimumLength(6, " Длина пароля должна быть не меньше 6 символов")
                .AsPassword();

            Configure(x => x.ConfirmPassword)
                .DisplayName("Пароль еще раз")
                .Required("Необходимо указать подтверждение пароля")
                .AsPassword()
                .Compare("Password", "Пароль и подвтерждение пароля должны совпадать");
        }
    }

Заключение

На этом первый этап конфигурирования MvcExtensions завершен. Если что-то осталось непонятно - задавайте вопросы, буду стараться разъяснять.

Бизнес-правила в DDD-2

noreply@blogger.com (hazzik) — Sun, 23 May 2010 13:29:00 +0000

Продолжу мучить сообщество своими вопросами по DDD дальше.

Допустим, мы хотим добавить в систему идентификацию не только по адресу электронной почты, но и по имени пользователя. В связи с этим у нас в системе возникает другое бизнес-правило:

Имя пользователя является уникальным

Это бизнес правило фигурирует в следующих историях использования:

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

Где должна находиться реализация данного бизнес-правила?

Жду ваших ответов с примерами кода в комментариях.

Бизнес-правила в DDD

noreply@blogger.com (hazzik) — Fri, 21 May 2010 20:40:00 +0000

У нас в системе есть одно очень интересное и достаточно распространенное бизнес-правило:

Адрес электронной почты пользователя должен быть уникальным в пределах системы.

public class User : IEntity
{
  public int Id { get; set; }

  public string Email { get; set; }

  public string Name { get; set; }
}

Где должна находиться реализация данного бизнес-правила?

Жду ваших ответов с примерами кода в комментариях.

PHP во вселенной .NET

noreply@blogger.com (hazzik) — Sun, 24 Jan 2010 17:39:00 +0000

Привет, сегодня я хочу рассказать о замечательном проекте Phalanger, который позволил прийти языку программирования PHP во вселенную .NET – и это не шутка! Phalanger – это компилятор PHP в IL-код.
Проект активно развивается, и скоро разработчики обещают выпустить новый релиз (предыдущий был в декабре 2008).

Проект Phalanger это:

Компилятор phpc;
Среда исполнения программ, написанных на PHP;
Расширение языка PHP/CLI;
Компоненты интеграции с Visual Studio.

Компилятор phpc позволяет компилировать PHP код в режиме совместимости (Legacy compilation mode), либо в режиме «чистый .NET» (pure .NET compilation mode). Режим совместимости позволяет любому вашему коду для родного интерпретатора компилироваться и работать без каких-либо проблем. Режим «чистый .NET» привносит более тесную интеграцию с .NET framework – можно использовать код, написанный на PHP/CLI, в других приложениях .NET.
PHP/CLI дополняет PHP такими родными для мира .NET фичами, как генерики, атрибуты и партиал классы (pure mode).
Новый релиз сулит нам следующие вкусности:

Поддержка спецификации PHP версии 5.3.1;
«Утиная» типизация для, еще более тесной, интеграцией с .NET;
Улучшенная интеграция с VS, с поддержкой IntelliSense;
Поддержку Silverlight 2.0;
И, конечно же, исправление багов, найденных с предыдущего релиза.

Также Phalanger уже поддерживает

Разработку WinForms приложений;
Разработку и отладку Silverlight 1.1 приложений;
ASP.NET 2.

Phalanger совместим со множеством бесплатных CMS, движков блогов и прочих PHP приложений. Данный проект, возможно, будет полезен тем, кто хочет постепенно изучить платформу .NET Framework и/или перейти на неё полностью c PHP.

Subversion vs. Git

noreply@blogger.com (hazzik) — Thu, 21 Jan 2010 22:21:00 +0000

Привет, сегодня я хочу поговорить о двух, по моему мнению, самых успешных системах контроля версий Subversion и Git. В своей практике я сталкивался с множеством VCS, включая такие экзотические системы как Jedi VCS. Мой личный путь миграции можно кратко описать так: CVS -> SVN -> Git.

Коммиты

Git благодаря наличию локального хранилища позволяет делать «отложенные» коммиты. «Отложенные» коммиты попадают в основное хранилище, только когда вы проталкиваете (push) их туда. Можно делать такие мелкие коммиты, какие вам захочется, не заботясь о том, красная полоска или зеленая – главное, чтобы при проталкивании изменений в основное хранилище полоска была зеленой (вы ведь пишите тесты?;)) Таким образом, коммит становиться для разработчика просто точкой возврата.

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

Ветки

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

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

Метаданные

SVN хранит метаданные по каждой папке отдельно в подпапках .svn. Этих метаданных чрезвычайно много, и при интенсивной работе над проектом (у нас каждый делает по 10-15 коммитов в день) файловая система сильно засоряется и часто приходиться производить дефрагментацию.

Git хранит метаданные более компактно, в одном месте - в подпапке .git корневой директории проекта. Но за всё нужно платить – нельзя скачать часть репозитория как в SVN, только весь.

Вместо заключения

Git благодаря своей огромной гибкости подходит для больших и/или распределенных команд, но более сложен в освоении.

SVN подходит для небольших команд из 2-3 человек, физически находящихся в одном помещении (хотя есть исключения).

Для операционных систем Windows для Subversion и Git есть очень удобные графические оболочки, встраивающиеся в проводник – TortoiseSVN и TortoiseGit соответственно.

Для тех кто хочет мигрировать с SVN на Git в состав Git включена утилита git-svn, позволяющая делать двустороннюю синхронизацию между хранилищами.

PHP: тестируем нетестируемое – echo

noreply@blogger.com (hazzik) — Sun, 03 Jan 2010 20:09:00 +0000

В данной заметке я хочу рассказать, как тестировать конструкции echo и ей подобные в PHP.

Допустим у нас есть такой код:


class World {
 public function printHello() {
   echo 'hello world';
 }

 public function printHello2() {
?>
   hello world
<?php
 }

//...

}

«Как же нам протестировать методы Hello и Hello2?» – вчера ночью этот вопрос загнал меня в тупик. Немного поразмыслив, я все-таки выкрутился из ситуации – для первого случая достаточно отрефакторить код таким образом, чтобы на вход конструкции echo подавался результат функции, вычисляющий требуемое значение:


class World {
 /** @returns string */
 public function getGreeting(){
   return 'hello world';
 }

 public function printHello(){
   echo $this->getGreeting();
 }

//...

}

Такой код уже поддается тестированию:


/** @test */
public function getGreetingReturnsHelloWorld () {
 $world = new World;

 self::assertEquals('hello world', $world->getGreeting());
}

Но как же быть во втором случае? Во втором случае нам поможет тестирование непрямого вывода . Перед вызовом тестовой системы добавим вызов функции ob_start() которая включает буферизированный вывод, а после вызова системы проверим содержимое буфера с помощью вызова функции ob_get_flush():


/** @test */
public function hello2InderectTesting () {
 $world = new World;

 ob_start();
 $world-> printHello2 ();
 $actual = ob_get_flush();

 self::assertEquals('hello world', $actual);
}

Причины перехода с LLBLGen Pro на NHibernate

noreply@blogger.com (hazzik) — Thu, 31 Dec 2009 16:34:00 +0000

Мой коллега уже описал пару причин, почему мы постепенно отказываемся от LLBLGen Pro в пользу NHibernate. Хочу добавить свои 50 центов.

Мы разрабатываем все проекты по методологии XP, активно используем принципы KISS и YAGNI, поэтому каждый проект, его доменная модель и, соответственно, база данных постоянно развиваются. С LLBLGen Pro нам приходилось генерировать модель несколько раз в день и, если одновременно нескольким разработчикам необходимо было что-то изменить – выстраивалась живая очередь.

С генерируемым кодом очень сложно использовать TDD – практически невозможно писать тест до кода. Чтобы написать тест необходимо проделать следующие шаги: добавить таблицу/поле/ограничение в базу; сгенерировать модель и только затем написать тест – это уже не TDD.

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

Сгенерированный код очень трудно рефакторить: нельзя просто переименовать сущность/поле/связь – необходимо сначала произвести переименование в проекте, потом в генераторе и затем заново сгенерировать модель.

NHibernate, же, позволяет переименовывать сущности как вам угодно прямо в Visual Studio (при условии, что для конфигурирования отображения используется fluent-nh) – необходимо будет только удостовериться, что рефакторинг произошел безболезненно – запустить тесты (а у вас ведь они есть ;-)).

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

Нет поддержки Value Object – т.е. невозможно из одной сущности выделить небольшие однообразные объекты, невозможно использовать связанную таблицу как Value Object.

Для отображения связи сущностей m:n используются также вспомогательные сущности, при этом сами коллекции m:n всегда прибывают в состоянии «только чтение»: чтобы добавить или удалить связанную сущность необходимо работать с коллекциями вспомогательных сущностей.

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

NHibernate лишен всех этих недостатков.

Вместо заключения

Ваш выбор LLBLGen если:

вам нужен очень быстрый старт и проект в дальнейшем не планирует своего развития либо поддержки;
вы разрабатываете проект с использованием тяжеловесных методик типа RUP и всяких там MSF, где вся система заранее детально проработана.

Ваш выбор NHibernate если:

ваша система находится в непрерывном развитии и вам необходима большая гибкость на уровне ORM

PS: всех с Новым годом ;-)

Асинхронный ввод-вывод. Проблемы

noreply@blogger.com (hazzik) — Thu, 12 Mar 2009 14:09:00 +0000

Проблема: допустим вы пишете простой -сервер, который получает какое-то сообщение от клиента, обрабатывает его и что-то ему отправляет. Протокол вы разрабатываете сами, на основе TCP/IP. Встает вопрос что выбрать: синхронные или асинхронные сокеты. Рассмотрим каждый вариант подробнее.

Типичная диаграмма последовательности для решаемой задачи

Синхронные сокеты.

При работе с синхронными сокетами, при вызове какой-либо операции текущий поток выполнения блокируется, до завершения операции. Ну ничего, решаете вы и выделяете по потоку на каждое соединение (или по два, если нужна независимая отправка). Пока ваше приложение маленькое, и пользуются им относительно небольшое количество одновременных пользователей, вы счастливы. Но как только количество пользователей переходит какой-то критический барьер - приложение начинает жутко тормозить. Давайте разберемся почему?

На каждый поток операционной системой выделяется определенный минимальный объем оперативной памяти (для стека и пр. - около 1 мб), при 500 пользователях это будет 500 МБ, без учета памяти потребляемой клиентом на выполнение своих операций.
Переключение между потоками выполнения занимает какое-то время.
Большинство потоков "висит" в ожидании завершения синхронной операции, при этом время на переключение между потоками продолжает тратиться.
Трудность отладки многопоточных приложений.

Для решения этих и других проблем синхронного ввода-вывода и придумали асинхронные вызовы.

Асинхронные сокеты

Для решения проблем выше были придуманы асинхронные сокеты и операции. При вызове асинхронной операции - поток выполнения не блокируется, а продолжает свое выполнение. В большинстве случаев асинхронные вызовы работают через так называемые порты завершения (IOCP). При вызове асинхронной операции сокет ассоциируется с каким-либо портом завершения, сокет будет оповещать этот поток о намерениях завершить операцию. При сигнале от сокета, порт берет из пула потоков (thread pool), свободный поток и завершает операцию (в зависимости от реализации может потребоваться вызвать метод завершения операции).
Что мы от этого выигрываем? Нет потоков ожидающих завершения операции, а следовательно потраченого впустую процессорного времени на переключение между ними; минимальное количество потоков; другие плюшки:)

Проблемы

При любом чтении или записи из сокета возвращается МЕНЬШЕЕ или равное ожидаемому количество байт. И если при работе с синхронными сокетами мы могли быть уверены, что получим сообщение полностью, написав цикл, который будет вычитывать строго необходимое количество данных в буфер (также для отправки, включая асинхронную). При асинхронном получении данных такой уверенности нет (при условии, что длина не фиксирована) - приложение просто выплюнет нам какой-то обрывок сообщения, или два, или полтора - как получиться. Таким образом необходимо будет потратить какое-то время на разбор приходящих сообщений.
Вторая проблема - т.к. асинхронные сокеты работают через нативный IOCP, то буферы для приема и отправки будут в состоянии pined. А множество пришпиленых объектов - зло, т.к. будет способствовать фрагментации кучи (подробнее тут), поэтому обычно принимается решение выделить один большой буфер, и использовать его постоянно. В .NET 2.0 появилась возможность вместе с асинхронными сокетами использовать ArraySegment{T}, который может "разбить" наш большой буфер на несколько небольших сегментов, но не все так просто, как кажеться - всем этим хозяйством необходимо управлять. Итого нам необходим менеджер сегментов (можно почитать тут), и парсер сообщений.

Асинхронный ввод-вывод

noreply@blogger.com (hazzik) — Wed, 11 Mar 2009 06:12:00 +0000

Привет. Кому-нибудь будет интересно почитать про асинхронный ввод-вывод, проблемы и их решения?

ASP.NET MVC Controls

noreply@blogger.com (hazzik) — Thu, 05 Mar 2009 04:04:00 +0000

Привет. На днях вышел ASP.NET MVC RC2, который в связку MVC + WebForms View Engine привнес привычные для ASP.NET-программистов контролы. Контролы лежат во фьчерс паке(он же Microsoft.Web.Mvc).

Давайте разберемся что нам это даст?

+ Design-time preview
+ Исчезнут так называемые code nuggets, все будет выполнено в стиле ASP:)
И самое главное - минусы:
- Скромные возможности data-binding, если с помощью хелперов можно было как-то настроить отображение данных (например привести к верхнему регистру), то тут только as is
- Работают только с вебформами (хотя это скорее фича).
В конечном итоге что использовать: расширения HtmlHelper или MVC Controls решать вам:)

Подробнее можно почитать у Eilon Lipton

Разработка динамического sitemap

noreply@blogger.com (hazzik) — Sat, 28 Feb 2009 13:43:00 +0000

Что такое sitemap, наверное знают все, кто не знает - может почитать тут или тут. Итак начнем, для начала создадим пару тестов, для вспомогательных методов:

[Fact]
public void XDocumentEquals() {
 XDocument expected = XDocument.Parse(@"<someTag>A</someTag>");
 XDocument actual = XDocument.Parse(@"<someTag>A</someTag>");
 Equal(expected, actual);
}

[Fact]
public void XDocumentNotEquals() {
 XDocument expected = XDocument.Parse(@"<someTag>A</someTag>");
 XDocument actual = XDocument.Parse(@"<someTag>B</someTag>");
 Assert.Throws<EqualException>(() => Equal(expected, actual));
}

И затем реализуем этот метод, он нам понадобиться для сравнения экземпляров класса XDocument.

public static void Equal(XObject expected, XObject actual) {
 Assert.Equal(expected.ToString(), actual.ToString());
}

При форматировании XDocument в строку, по умолчанию стоит кодировка "utf-16", а нам бы хотелось "utf-8", поэтому напишем тест для функции-расширения XDocument.ToXml():

public class XDocumentExtensionsFacts {
 [Fact]
 public void ToXml() {
     var expected = @"<?xml version=""1.0"" encoding=""UTF-8""?>
 <root />";
     var xdoc = new XDocument(new XElement("root"));
     var actual = xdoc.ToXml();
     Assert.Equal(expected, actual, StringComparer.Create(CultureInfo.CurrentCulture, true));
 }
}

И получим примерно такую реализацию:

public class EncodedStringWriter : StringWriter {
 private readonly Encoding _encoding;

 public EncodedStringWriter(Encoding encoding) {
     _encoding = encoding;
 }

 public EncodedStringWriter() : this(Encoding.UTF8) {
 }

 public override Encoding Encoding {
     get { return _encoding; }
 }
}

public static class XDocumentExtension {
 public static string ToXml(this XDocument doc) {
     using(var writer = new EncodedStringWriter()) {
         doc.Save(writer);
         return writer.ToString();
     }
 }
}

Создадим класс SiteUrl, который будет хранить информацию о url'ах сайта, и уметь сериализоваться в XElement, для этого напишем несколько тестов:

public class SiteUrlFacts {
 [Fact]
 public void Constructor() {
     var expected = new Uri("http://somesite.com");
     var target = new SiteUrl(expected);
     Uri actual = target.Location;
     Assert.Equal(expected, actual);
 }

 [Fact]
 public void PriorityLessThenZeroThrowsException() {
     var target = new SiteUrl("http://somesite.com");
     int illegalPriority = new Random().Next(int.MinValue, 0);
     Assert.True(illegalPriority < 0);
     Assert.Throws<NotSupportedException>(() => target.Priority = illegalPriority);
 }

 [Fact]
 public void PriorityMoreThenOneThrowsException() {
     var target = new SiteUrl("http://somesite.com");
     int illegalPriority = new Random().Next(1, int.MaxValue);
     Assert.True(illegalPriority > 1);
     Assert.Throws<NotSupportedException>(() => target.Priority = illegalPriority);
 }

 [Fact]
 public void PrioritySetNormal() {
     var target = new SiteUrl("http://somesite.com");
     var normalPriority = (float)(new Random().NextDouble());
     Assert.True(normalPriority >= 0);
     Assert.True(normalPriority <= 1);
     target.Priority = normalPriority;
 }

 [Fact]
 public void SerializeHasAllArguments() {
     XElement expected = XElement.Parse(
         @"<url xmlns=""http://www.sitemaps.org/schemas/sitemap/0.9"">
 <loc>http://www.example.com/</loc>
 <lastmod>2005-01-01T00:00:00 05:00</lastmod>
 <changefreq>monthly</changefreq>
 <priority>0.8</priority>
</url>");
     var siteUrl = new SiteUrl("http://www.example.com/") {
         LastModified = new DateTimeOffset(new DateTime(2005, 01, 01)),
         ChangeFrequency = ChangeFrequency.Monthly,
         Priority = 0.8f,
     };
     XElement actual = siteUrl.Serialize();
     XObjectAssert.Equal(expected, actual);
 }
}

Ну и соответственно реализация:

public enum ChangeFrequency {
 Always,
 Hourly,
 Daily,
 Weekly,
 Monthly,
 Yearly,
 Never,
}

public class SiteUrl {
 private float? _priority;

 public SiteUrl(string location)
     : this(new Uri(location)) {
 }

 public SiteUrl(Uri location) {
     Location = location;
 }

 public Uri Location { get; private set; }
 public DateTimeOffset? LastModified { get; set; }
 public ChangeFrequency? ChangeFrequency { get; set; }

 public float? Priority {
     get { return _priority; }
     set {
         if(value < 0 || value > 1) {
             throw new NotSupportedException("Priority must be between 0 and 1");
         }
         _priority = value;
     }
 }

 public virtual XElement Serialize() {
     return new XElement(SiteMapBuilder._sitemap   "url",
                         new XElement(SiteMapBuilder._sitemap   "loc", Location),
                         LastModified.HasValue
                             ? new XElement(SiteMapBuilder._sitemap   "lastmod",
                                            LastModified.Value.ToString("yyyy-MM-ddTHH:mm:ss%K"))
                             : null,
                         ChangeFrequency.HasValue
                             ? new XElement(SiteMapBuilder._sitemap   "changefreq",
                                            ChangeFrequency.Value.ToString().ToLower())
                             : null,
                         Priority.HasValue
                             ? new XElement(SiteMapBuilder._sitemap   "priority",
                                            Priority.Value)
                             : null);
 }
}

Дальше необходимо написать класс, который будет уметь сериализовать в XML коллекцию SiteMap'ов. напишем соответствующие тесты:

public class SiteMapBuilderFacts {
 [Fact]
 public void CreateEmptySitemap() {
     XDocument expected = XDocument.Parse(
         @"<?xml version=""1.0"" encoding=""UTF-8""?>
<urlset xmlns=""http://www.sitemaps.org/schemas/sitemap/0.9"" />");
     XDocument actual = new SiteMapBuilder(new List<SiteUrl>()).Build();
     XObjectAssert.Equal(expected, actual);
 }

 [Fact]
 public void CreateSitemapWithOneElement() {
     XDocument expected =
         XDocument.Parse(
             @"<?xml version=""1.0"" encoding=""UTF-8""?>
<urlset xmlns=""http://www.sitemaps.org/schemas/sitemap/0.9"">
<url>
<loc>http://www.example.com/</loc>
</url>
</urlset>");
     var urlset = new List<SiteUrl> { new SiteUrl("http://www.example.com/") };
     XDocument actual = new SiteMapBuilder(urlset).Build();
     XObjectAssert.Equal(expected, actual);
 }
}

И реализуем:

public class SiteMapBuilder {
 public static readonly XNamespace _sitemap = "http://www.sitemaps.org/schemas/sitemap/0.9";
 private readonly IEnumerable<SiteUrl> _urlset;

 public SiteMapBuilder(IEnumerable<SiteUrl> urlset) {
     _urlset = urlset;
 }

 public XDocument Build() {
     return new XDocument(new XElement(_sitemap + "urlset", _urlset.Select(x => x.Serialize())));
 }
}

И теперь осталось самое главное - как прикрутить это к ASP.NET? можно так:

<%@ WebHandler Language="C#" Class="SiteMapHandler" %>
using System;
using System.Collections.Generic;
using System.Web;
using Hazzik.SiteMap;

public class SiteMapHandler : IHttpHandler {
 #region IHttpHandler Members

 public void ProcessRequest(HttpContext context) {
     var urlset = new List<SiteUrl> { new SiteUrl("http://localhost/") };
     var xml = new SiteMapBuilder(urlset).Build().ToXml();
     HttpResponse response = context.Response;
     response.Clear();
     response.ContentType = "text/xml";
     response.Write(xml);
     response.End();
 }

 public bool IsReusable {
     get { return true; }
 }

 #endregion
}

Для ASP.NET MVC можно написать примерно следующую реализацию ActionResult:

public class SiteMapResult : ActionResult {
 private readonly IEnumerable<SiteUrl> _map;

 public SiteMapResult(IEnumerable<SiteUrl> map) {
     _map = map;
 }

 public IEnumerable<SiteUrl> Map {
     get { return _map; }
 }

 public override void ExecuteResult(ControllerContext context) {
     string xml = new SiteMapBuilder(Map).Build().ToXml();
     HttpResponseBase response = context.HttpContext.Response;
     response.ContentType = "text/xml";
     response.Write(xml);
 }
}

Ну а дальше я думаю разберетесь, удачи:)
Строго не серчайте, это моя первая запись на техническую тему, да и русским литературным я не очень хорошо владею:) Замечания и комментарии приветствуются:)