© 2000–2012 NoNaMe
Попробуем теперь перейти к реализации принятых ранее решений.
Начанём с организации системы маппинга.
Для начала определим атрибуты атрибуты, которые в дальнейшем будут определять маппируемые поля и классы.
MappedClassAttribute. Этот атрибут определяет маппируемые классы. Как мне кажется наделить этот аттрибут достаточно одним свойством — названием таблицы, в которой будут хранится сущности этого типа. Для удобства можно сделать следующий \"финт ушами\": если атрибут определён над каким-либо классом, но имя таблицы не задано, то определять это имя по названию класса. Это будет достаточно удобно, если описать базовый класс маппируемых сущностей и поставить над ним атрибут MappedClassAttribute. В таком случае атрибут будет унаследован всеми потомками, а конкретного задания имени таблицы не требуется. Для определения названия таблицы я решил использовать следующий метод:
MappedFieldAttribute. Тут я тоже решил, что достаточно ограничиться названием поля в таблице для отображения поля класса. Продолжая следовать принципу \"лучше написать один раз много, чем потом по сто раз что-то приписывать\" метод для определения имени у поля (если не задано конкретно) так же написал чуть-чуть гуманее и основываясь на том, что в C# названия приватных полей принято начинать со знака подчёркивания:
KeyFieldAttribute. Как показывает практика не редко используются автогенерируемые поля (счётчики, автоинкрименты — названий много встречалось). В таком случае необходимо дать понять нашей системе, что при генерировании INSERT-запроса нет нужды учитывать такое вот поле. На большинстве SQL-серверов такие попытки вообще заканчиваются ошибкой. Из этих соображений атрибут ключевого поля кроме имени поля таблицы я наделил ещё одним свойством: признак автогенерируемости.
Этих атрибутов должно хватить для описания принципов маппирования для сущностей.
Едем дальше. Опишем интерфейс мапперов. По сути маппер должен уметь выполнять 5 операций: Accept, Create, Read, Update, Delete. На этом и остановимся:
И теперь \"ядро\" нашей системы — сам портал (GateWay). Как и описывалось в теоритической части список методов, которые должен предоставлять GateWay выглядит следующим образом: RegisterMapper, UnregisterMapper, Create, Read, Update, Delete.
Теперь перейдём к тестированию. Для этого создадим дополнительный проект с тестами. поместим туда свой маппер, который будет пригоден только для тестирования. Для этого нам придётся реализовывать интерфейс IMapper. Сделаем это всё следующим образом:
1). Маппер наделим свойством UsageCount — количество использований.
2). При создании маппера обнуляем UsageCount.
3). При вызове любого метода увеличиваем UsageCount на 1.
4). Метод Accept проверяет переданный параметр на тип. Если тип int — то соглашаемся работать с этой сущностью, если нет — то отказываемся.
При таком пдходе тестирование можно произвести следующими действиями:
1). Регистрируем наш тестовый маппер.
2). Вызываем например Create, а параметром передаём int\'овую переменную.
3). Проверям UsageCount у нашего маппера — оно должно равняться 2, так как вызовов должно быть 2: Accept и Create.
4). Вызываем какой-либо метод передавая туда переменную типа отличного от int (double например).
5). Проверяем количество вызовов у маппера. Их должно быть 3: 2 старых и один новый вызов Accept.
После того как тесты отработают можно считать, что основа положена — ядро системы маппинга написано и проверено. После этого можно уже разделить работу: один пишет конкретную реализацию маппера (может и не один, если мапперов много надо), а второй (опять же может и не один) начинает описывать поведение бизнес-объектов и расставлять в нужных местах атрибуты.
Теперь об исходниках. Я думаю, что понять то, о чём я пишу не так уж и легко (это и мне минус тоже :) ). Зато имея исходники перед глазами можно и разобраться. Поэтому выкладываю исходники на общее обозрение:
© 2000–2012 NoNaMe