Sunday, March 29, 2009

Entity Framework vNext: сущности, сами отслеживающие свои изменения

Команда ADO.NET продолжает свой эксперимент по публичному проектированию следующей версии Entity Framework. Надо сказать, что результаты пока что весьма спорны: с одной стороны, они действительно публикуют все идеи и предлагают их обсуждать, с другой - очень часто возникает впечатление, что все решения уже приняты, и максимум, на что можно рассчитывать - это какие-то незначительные изменения в деталях.

Вот, например, одно из последних нововведений - это концепция сущности, которая сама отслеживает свои изменения. Я поначалу не до конца понял идею и до середины статьи думал, что ADO.NET team решил реализовать сделать свою версию Castle ActiveRecord, воспользовавшись одноименным паттерном. Однако потом я-таки въехал в идею - никакого Active Record там нет. Смысл в том, что теперь у разработчиков появится возможность сгенерировать достаточно "умные" сущности (при помощи T4), которые будут сами отслеживать свое состояние и фиксировать изменения. Сохранять изменения в таких сущностях вы сможете просто вызвав метод ApplyChanges у ObjectContext, которому вы можете передать подобный объект (да, наверно, и коллекцию). Кроме того, если вы просто создадите эту сущность, она будет жить с состоянием Added до тех пор, пока кто-то не решит записать ее в базу. Фактически, теперь вы можете создать сущность при помощи одного контекста, а потом сохранить при помощи другого, то есть сущность становится намного более независимой от контекста, который ее породил. В статье подобная сущность даже называется POCO-объектом, хотя все-таки до true POCO там еще далеко.

Что же тут такого полезного? Ведь и раньше вроде бы можно было отсоединять сущности от одного контекста, и присоединять их потом к другому. Можно было, но только вот все изменения сущности при этом терялись как при отсоединении, так и при присоединения, т.к. сущности первой версии не обладают способностью отслеживать свои изменения, эта функция доступна лишь контексту. И это как раз и порождало кучу проблем, связанных с тем, что для обеспечения нормального взаимодействия между несколькими сущностями, было необходимо, чтобы они были созданы в одном и том же контексте. А это не очень приятно для сценариев, в которых сущности живут в приложении немножко дольше, чем время вызова одного-двух методов. Теперь же эта проблема решена.

Однако, лично у меня возникает один вопрос: как быть с ассоциациями (навигационными свойствами)? Теперь, когда сущность отделена от контекста, она не может им воспользоваться для того, чтобы заполнить данными незагруженное навигационное свойство. Как быть? Задал вопрос разработчикам там же в комментариях - может, ответят.

Другие нововведения:

1) Новый тип ассоциаций (foreign key)
2) Упрощенная настройка шаблонов генерации сущностей (T4)
3) Функции, определяемые в модели
4) Общие улучшения для N-tier архитектур
5) Концепция подхода Model First
6) и многое другое (там действительно куча информации)

PS. Надо сказать, нашумевший Vote of no confidence, о котором я уже писал, сделал свое дело, и вторая версия EF будет намного более солидной и зрелой. Еще бы немножко улучшить производительность - и будет достаточно интересная альтернатива NHibernate.

Saturday, March 21, 2009

Материалы доклада по ASP.NET MVC

Как я и обещал, выкладываю материалы доклада по ASP.NET MVC, который я делал в прошедшую пятницу, 20 марта, на очередной встрече UNETA в Харькове.

Презентация:

Исходный код тестового приложения выкладывать не буду, т.к. есть отличный пример http://nerddinner.codeplex.com/, о котором я уже упоминал, и к которому мне особо добавить нечего. Пользуйтесь им для ознакомления и изучения. Очень маленькое 185-страничное описание этого приложения можно найти здесь, а живую попытку Скотта Хенселмана (Scott Hanselman) написать это приложение перед широкой аудиторией за 75 минут с перерывами на шутки - здесь. Кстати, там внизу можно его скачать и насладиться просмотром на скорости 1.3-1.4, если у вас не так много времени :) На главной странице MIX'09 вы также можете найти кучу других интересных докладов, особенно по ASP.NET MVC и Silverlight. Такое впечатление, что MIX'09 прошел под эгидой этих двух технологий. В общем, рекомендую.

Да! Чуть не забыл. А если все получится, то, возможно, чуть позже будет еще и видео :)

Wednesday, March 18, 2009

ASP.NET MVC 1.0 released

Я еще не нашел официального подтверждения, но на Microsoft Downloads он уже висит:

http://www.microsoft.com/downloads/details.aspx?FamilyID=53289097-73ce-43bf-b6a6-35e00103cb4b&displaylang=en

Думаю, в ближайшее время об этом будет официально объявлено на MIX'09 :)

Вдобавок сообщаю, что в эту пятницу, 20 марта, я буду делать доклад по ASP.NET MVC на харьковской UNETA. Какое приятное совпадение, правда? :) Так что с одной стороны поздравляю всех, что ЭТО произошло, а с другой приглашаю на нашу встречу. С учетом того, что второй доклад будет по Silverlight, а докладчиками будут Сергей Лутай и Андрей Каща, уверен, что будет интересно.

Приходите.

Friday, March 13, 2009

Обеды для гиков

Несколько всем известных гиков (nerds, geeks), Scott Guthrie, Scott Hanselman, Rob Conery и Phil Haack, пишут книгу об ASP.NET MVC, который они же, собственно, и разрабатывают. Книжка эта, надеюсь, будет доступна уже довольно скоро, а пока что они решили выложить отрывок книги в бесплатный доступ. В отрывке этом описывается процесс создания сайта http://www.nerddinner.com, который предназначен для того, чтобы помочь другим гикам отрываться от своих любимых компьютеров, собираться в кучки за завтраком/обедом/ужином и обсуждать свои гиковские темы под пиво/виски/сок.

Так что всем, кто хочет побыстрее окунуться в изучение новой веб-технологии, и заодно на реальном примере посмотреть, как правильно разрабатывать приложения на ASP.NET MVC, рекомендуется зайти на http://nerddinner.codeplex.com и скачать оттуда исходный код и тесты.

Тем же, кто проникнулся идеей организовать первый гиковский обед на просторах бывшего СССР, никто не запрещает это делать. Жаль только, что сайт этот пока что не сильно распространен в нашей части света, поэтому не ожидайте большого наплыва желающих, разве что вы не пнете их сами :)

Посты авторов об этом событии:

http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx
http://www.hanselman.com/blog/FreeASPNETMVCEBookNerdDinnercomWalkthrough.aspx
http://blog.wekeroad.com/blog/nerddinner-and-a-free-book/
http://haacked.com/archive/2009/03/10/chapter-one-pro-aspnetmvc.aspx

Кстати, кто еще не успел проникнуться идеей о том, что MVC – это шаг в правильном направлении для веб-разработки и наше общее будущее, можете узнать о нем больше на официальном сайте, где уже собралось довольно много материалов и видео-уроков, полностью описывающих процесс создания приложения и различные tips & tricks. И еще, кроме блогов вышеперечисленных товарищей, рекомендую блог Stephen Walther’а, который содержит ОЧЕНЬ много советов и трюков по ASP.NET MVC и отрывки из будущей книги Стивена по все тому же ASP.NET MVC.

Приятных обедов! :)

Thursday, March 12, 2009

О философии в программировании (и не только)

Очень понравились несколько философских фраз, которые запросто подходят и к программированию, поэтому оставляю здесь – удобно ссылаться в будущем, и, может, кто-то еще не видел :)

Классика кунг-фу (взято с RSDN):

Сначала ты не знаешь, что нельзя делать то-то.
Потом знаешь, что нельзя делать то-то.
Потом ты понимаешь, что иногда таки можно делать то-то.
Ну, а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться желаемого, и все из них практически равноправны.
Когда тебя спрашивают "как мне добиться желаемого", ты быстро перебираешь в уме эти шестьдесять шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: "Вообще-то, главное – это гармония."
И на вопрос обиженных учеников: "А как ее добиться?", ты говоришь: "Никогда не делайте то-то".

Сколько раз уже убеждался в простоте и правоте этой формулировки…

Искусство мыть слона

Слон большой. В нём много работы вообще и даже много разных видов работ. Нужно знать, что делать, когда делать, когда переставать это делать.
* Какую часть слона ты начнёшь мыть первой?
* Когда сочтёшь её чистой и перейдёте к следующей части?
* Как, собственно, убедить других, что слон уже вымыт (у них может быть и, по-видимому, действительно будет своё мнение по этому вопросу)?

Суть в том, что не стоит браться за мытье сразу всего слона. Ответь на мелкие вопросы и получишь более полный ответ и понимание, куда двигаться дальше.

За последнее особая благодарность Андрею Каще, который привел эту фразу в качестве аргумента в нашей дискуссии. Да, и еще Андрей недавно написал очень хорошую статью по модульному тестированию.

Wednesday, March 11, 2009

Кеширование и Silverlight

На днях столкнулся на работе с интересной ситуацией, которая в который раз напомнила о том, что .NET веб-программирование - это не только ASP.NET, но еще и куча всего под ним, благодаря чему этот ASP.NET, собственно, и работает. И что знание одного лишь ASP.NET не делает вас настоящим веб-программистом. Нужно знать еще много чего, начиная от HTML/CSS/JS и вплоть до протокола HTTP (хотя бы в какой-то мере). Вот и в нашем случае для решения проблемы понадобились знания HTTP-кеширования...

HTTP-кеширование - это кеширование страниц и других запрашиваемых ресурсов на машине пользователя или промежуточных прокси-серверах. Делается это, естественно, для того чтобы не загружать их постоянно с сервера и таким образом уменьшить трафик и увеличить производительность приложения. Управление кешированием происходит при помощи HTTP-заголовков. Для управления кешированием используются следующие заголовки: Expires, Last-Modified/If-Modified-Since, ETag/If-None-Match, Cache-Control, Pragma, X-Cache (который не является стандартным HTTP-заголовком, но тем не менее используется веб-серверами и прокси-серверами вроде squid) и т.д.

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

Итак, есть Silverlight-приложение, которое на веб-сервере представлено XAP-файлом. Наверно, вы в курсе, что во избежание постоянных загрузок этих иногда очень даже немаленьких файлов с сервера, XAP-файлы по умолчанию кешируются в браузере. Ну, как обычные ZIP-файлы, например. Так вот, заливаем мы обновленную версию XAP-файла на удаленный сервер, пробуем запустить с одного компьютера - приложение обновлено, с другого - нет, показывается старая версия (тут необходимо отметить, что компьютеры находятся в разных локальных сетях). Ну, закешировал браузер, с кем не бывает. Очищаем кеш в FF - не работает, по-прежнему старая версия. Делаем Ctrl-F5 в IE - то же самое. Никаких изменений. Чешем репу, пробуем еще раз. И еще раз. С разными вариациями. Лезем в гугл - гугл что-то говорит по поводу кеширования SL-приложений, что нужно настроить в IIS опцию не кешировать приложение (свойства XAP файла в IIS -> HTTP Headers таб -> "Enable Content Expiration" -> "Expire Immediately" с вариациями в зависимости от версии IIS). Пробуем - не получается. Похоже, придется все-таки включать голову. Берем Fiddler, запускаем, смотрим запросы на XAP-файл. Так и есть, берет из кеша браузера. Делаем Ctrl-F5 - запрос уходит, файл получен заново... но он старый! Быстро вспоминаем, где еще могут быть закешированы файлы - на прокси-серверах. Ага! Быстрая проверка с удалением файла на сервере, который тем не менее, отлично заново откуда-то загружается подтверждает теорию. HTTP-заголовки тоже ее подтвержают:

Date: Thu, 05 Mar 2009 09:08:19 GMT
Age: 454965

Значит, файл действительно закеширован на прокси-сервере. Заголовок X-Cache (если вам повезло и он есть) позволяет даже узнать на каком:

X-Cache: HIT from <domain.com>

Здесь <domain.com> - адрес нашего родного корпоративного проксика :) Дальше дело за малым - перенастроить squid, чтобы он не кешировал запросы с корпоративного staging-сервера - и готово. Или еще не готово?

Конечно, не готово. А если у клиента или его end-user'ов прокси-сервер тоже настроен таким же образом? С одной стороны, это не так страшно, если вы не собираетесь часто обновлять приложение, но с другой стороны наш случай показал, что простое обновление файла НЕ СБРАСЫВАЕТ кеш прокси-сервера! То есть браузер получает файл прямо из прокси, а тот даже думать не желает лезть за обновлением на веб-сервер. Почему? Так настроен Cache-Control, который, во-первых, public (то есть доступен для кеширования не только в браузере, но и на прокси-серверах), а во-вторых, не содержит опции по проверке обновления файла по умолчанию. Из этого следует, что в случае, если между приложением и клиентом находится кеширующий прокси, и вы обновили приложение, то пользователи не увидят его до тех пор, пока кеш прокси-сервера не сбросится. А это не всегда приемлемо.

Как же решить проблему раз и навсегда? Можно рубануть с плеча и поступить так, как советуют люди, установив опцию "Expire Immediately" для вашего XAP-файла в IIS. Но если вы сделаете это, то у вас КАЖДЫЙ запрос пользователя будет заканчивать перезагрузкой файла с сервера. Что при размере последнего больше 500 Кб-1 Мб равносильно самоубийству в особо извращенной форме для какого-нибудь вебдванольного сайта с большим количеством посещений. Есть ли способ гуманнее? Да, есть, хотя я еще и не пробовал его, поэтому действуйте на свой страх и риск. Поскольку IIS не дает нам сильно разбежаться в плане установки своих кастомных заголовков для файлов, то здесь в одном из ответов рассказывается, как сделать HTTP-хендлер, который будет устанавливать необходимые заголовки (как минимум Cache-Control: private для production и no-cache или даже no-store для девелоперских машин). К слову, это же поможет вам и в девелопменте, т.к. каждый раз давить Ctrl-F5 или очищать кеш в FF - это тоже не выход, на мой взгляд. Описывать реализацию не буду - думаю, сами справитесь да и время уже позднее :)

Удачи вам в Silverlight-девелопменте!

Thursday, March 5, 2009

Будущее тестирования от Microsoft

Всем девелоперам, QA и менеджерам советую подкаст .NET Rocks по тестированию. В гостях – James Whittaker, Software Architect из Microsoft, который всю жизнь посвятил тестированию, а также написал кучу научных работ, посвященных этому предмету.

Девелоперам стоит послушать про то, что такое тестирование на самом деле, чем отличается тестирование на стороне девелопмента и на стороне тестирования, а также, наконец, понять, что QA – это не человек, который хочет сломать то, что ты написал, а человек, проверяющий качество продукта и несущий за это качество ответственность. Также немного обсуждается unit-тестирование, TDD и работа с legacy-кодом.

QA стоит послушать про то, как тестируют в Microsoft, как Джеймс понимает тест кейсы, в чем их проблемы, что такое покрытие тест кейсами продукта и как достичь его максимума. Но самое главное, Джеймс рассказывает кое-что про новые фичи VS 2010 для тестирования и свои идеи про то, как должно выглядеть тестирование в будущем. Test cases, которые сами оповещают QA, что их необходимо проверить после изменения кода. Или которые являются переносимыми и настолько умными, что могут сами определить, что именно нужно протестировать на новом проекте. Или автоматические тесты, которые подобно нанороботам расползаются по приложению и тестируют его сами. Ну, это уже фантастика, но компьютер когда-то тоже был фантастикой :) В общем, взрыв мозга в определенной степени.

Менеджерам и лидам стоит послушать про организацию тестирования в Google и Microsoft, а также размышления на тему, какое должно быть соотношение девелоперов к тестерам.

И еще пара шуток оттуда же:

- why did it take God only seven days to create the universe?

- no installed dates, no legacy to screw up. You want a planet there, put a planet there. Super nova there...

-----------------------

Возможно, вы уже слышали, что green field – это код, который пишется с чистого листа, а brown field – это код, который пишется на базе другого кода (legacy). Ну, аналогия понятна: зеленая трава, пожухлая трава. Brown field очень часто дает кучу проблем на голову, т.к. нужно слишком много поменять, чтобы продолжить работу. Так что есть еще одна аналогия :) “It was the Greenfield and Brownfield development and I like to joke that we know what's making the field brown, don't we? :)”

В общем, рекомендую. И наверно, буду почаще что-то стоящее рекомендовать из того, что слушаю.