Введение

Слишком много раз я встречал приложения, о которых говорили, что у них есть модель предметной области и приложение было спроектировано на основе это предметной области. Однако в действительности всё, что я видел, было коллекцией сущностей (я бы даже сказал DTO), имеющих кучу свойств без какой бы то ни было реальной логики, связанной с сущностью. Кроме того, я могу найти много сервисов всех видов, которые содержат красочную смесь бизнес-логики и/или инфраструктуры. Если приложение вдобавок использует шину сообщений (как NServiceBus, Mass Transit Bus или Azure Bus), то конечно же заметно, что некие сообщения передаются от одного модуля к другому или нескольким модулям. К сожалению, сообщения часто имеют очень обобщённые названия, содержащие слова “обновить”, “изменить”, “добавить” или “удалить”, и несут большое количество полезной нагрузки — десятки разнообразных свойств. Часто из названия сообщения совершенно не очевидно, является ли оно командой или событием, и чтобы определить это, приходится глубоко зарыться в реализацию.

Я искренне хотел бы, чтобы все написанное выше было бы преувеличением или же имело смысл только для «старых» приложений, которые разрослись и вышли из-под контроля. Но печальная истина в том, что это относится ко многим новым проектам, даже тем, которым всего несколько месяцев от роду. Почему так происходит? Конечно, есть много разных причин: отсутствие знаний является одной из наиболее важных.

Into

Под .NET существует две родных ORM, разрабатываемых и поддерживаемых Microsoft, — Entity Framework и Linq2Sql. Однако Entity Framework продолжает развиваться внушительными темпами, а про будущее Linq2Sql ничего толком неизвестно.

Entity Framework предлагает удобный дизайнер, огромное количество вариантов маппинга, автогенерацию классов-моделей, но на все это есть жирный минус – гигантские и раздутые сгенерированные классы, которые к тому же нельзя изменять вручную – ибо при каждом изменении модели в дизайнере, все будет пересоздано заново. Сравните это с чистыми классами, и добавленными к ним атрибутами, как в Linq2Sql, и вы поймете, почему такое количество людей заявляет о легковесности Linq2Sql и монструозности EF.

Конечно, каждая проблема имеет решение, и эта не исключение. Частичные классы позволят добавить нужный функционал, а специально созданные классы с правилами валидации, помеченные атрибутом [MetadataType], дадут возможность использовать атрибуты валидации для классов-моделей. Но вместе это получается не очень красиво – размазанные по проекту классы, увеличение их количества, и все та же сложность в поддержке.

Не стоит также забывать об условиях работы классов-моделей: они должны либо наследоваться от EntityObject или реализовывать интерфейсы EntityWithKey, IEntityWithChangeTracker и IEntityWithRelationships

Так что же делать тем, кто хочет получить максимально простые классы для работы внутри ORM?

Основная идея юнит (или модульного, как его еще называют) тестирования – тестирование отдельных компонентов программы, т.е. классов и их методов. Разрабатывать код, покрытый тестами, весьма полезно, потому что при их правильном использовании практически исключается возможность регресии в истории развитии программы – «что-то новое добавили, половина старого слегла». Также сейчас весьма модна методология разработки “TDD” — Test Driven Development. Согласно ей, программист вначале разрабатывает набор тестов для будущей функциональности, просчитывает все варианты выполнения, и лишь потом начинает писать непосредственно рабочий код, подходящий под уже написанные тесты.

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