[ObjectFactory(typeof(Person.ObjectFactory), "PersonType")]
public class Person
{
[MapField("PersonID")]
public int ID;
public string LastName;
public string FirstName;
public string MiddleName;
class ObjectFactory : IObjectFactory
{
public object CreateInstance(TypeAccessor typeAccessor, InitContext context, string selectorFieldName)
{
// Get the object type indicator field.
//object objectType = context.DataSource.GetValue(context.SourceObject, selectorFieldName);
// Target ObjectMapper must be changed in order to provide correct mapping.
//switch ((string)objectType)
{
case"D": context.ObjectMapper = ObjectMapper<Doctor>. Instance; break;
case"P": context.ObjectMapper = ObjectMapper<Patient>.Instance; break;
}
// Create an object instance.
// Do not call ObjectMapper.CreateInstance as it will lead to infinite recursion.
//return context.ObjectMapper.TypeAccessor.CreateInstance(context);
}
}
}
что бы можно было делать так:
List<Person> list = new SqlQuery(db)<Person>.SelectAll();
А то ради того, чтобы запросить из вьюшки подобные данные, приходится либо руками запрос писать, чтобы в него нужное поле попало, либо проперти PersonType в класс добавлять, которае там нафиг не сдалось.
Здравствуйте, albenik, Вы писали:
A>А то ради того, чтобы запросить из вьюшки подобные данные, приходится либо руками запрос писать, чтобы в него нужное поле попало, либо проперти PersonType в класс добавлять, которае там нафиг не сдалось.
на счет примера, я вроде как, он синтетический, а из вашего примера ну ничего не ясно... так например, откуда в кортеже возмется колонка PersonType?
я, лично, пользую фабрику при хранении наследников в одной таблице.
а там, без явного указания типа никак не обойтись... а что поделать?... с точки зрения ОО поле Id тоже нафиг не сдалось
Здравствуйте, ili, Вы писали:
ili>на счет примера, я вроде как, он синтетический, а из вашего примера ну ничего не ясно... так например, откуда в кортеже возмется колонка PersonType?
Пример это всего-лишь легонькая переделка этого примера http://bltoolkit.net/doc/Reflection/ObjectFactory.htm, т.е. хочеться все как в примере BLToolkt'a, но получать итоговый список наследников Person не через db.SetCommаnd("SOME_SQL_QUERY").ExecuteList<BaseT>(); а через new SqlQuery<BaseT>().GetAll(); Чтобы не писать запрос руками.
Тогда можно спокойно написать и использовать наследника от SqlQuery и делать GetЧегоДушаПожелает(), а иначе куда не плюнь при наличии во фреймворке отличного SqlQuery, как только нужно поработать с фабрикой объектов сразу надо руками SQL писать.
Собственно я наследника от SqlQuery и написал и прекрасно им пользовался пока в ObjectFactory не уперся.
Или я чего-то не понял в идеологии.
Кстати мой пример, все равно, нифига работать не будет, т.к. SqlQuery cгенерит SQL запрос, используя список полей только базового класса.
ili>я, лично, пользую фабрику при хранении наследников в одной таблице.
Не совсем понял, в приведенном примере, тоже фабрика используется или мы о разных вещах говорим?
ili>а там, без явного указания типа никак не обойтись... а что поделать?... с точки зрения ОО поле Id тоже нафиг не сдалось
давай расставим все черточки над й, как работает мапинг:
1) исполнение запроса, получение DataReader
2) для каждой строчки DataReader создается объект в который будет осуществлен маппинг, тип объекта указывается явно, либо через параметр, либо через генерик
3) строчка ДатаРидера мапится на полученный на шаге 2 объект
итак, нас интересует шаг 2: объект _всегда_ создается при помощи TypeAccessor.CreateInstanceEx(InitContext context)
CreateInstanceEx проверяет, ассоциирована ли фабрика с данным типом, если да, то делегирует создание объекта ей, если нет, создает сам (NB: CreateInstance в отличии от CreateInstanceEx всегда пользуется только услугами TypeAccessor не ища никакую фабрику).
итого, абсолютно неважно кто вызовет dbManager.ExecuteXXX(...) — фабрика все равно будет использована.
да про одно и тоже, но по ходу чего-то друг друга недопонимаем.
поделюсь про свой опыт.
итак, у мя есть вагончик наследников от базового класса, все они хранятся в одной табличке, ибо так проще.
каждый класс имеет поле Type которое инициализируется в конструкторе "ручками" (в табличке,это поле тоже есть).
SqlQuery я тупо подпилил, так что бы для SelectAll генерился запрос "SELECT * FROM [Table]"
плюс сделал "SelectAllOfType" — он генерит "SELECT * FROM [Table] WHERE [Type] = @type"
инсерты/апдейты/делиты не трогал.
итого, если не считать, что пользуется "*" вместо перечисления полей, и одно служебное (и вправду нафиг не сдавшееся) поле с идентификатором типа, все арбайтен.
Здравствуйте, ili, Вы писали:
ili>SqlQuery я тупо подпилил, так что бы для SelectAll генерился запрос "SELECT * FROM [Table]" ili>плюс сделал "SelectAllOfType" — он генерит "SELECT * FROM [Table] WHERE [Type] = @type" ili>инсерты/апдейты/делиты не трогал.
Здравствуйте, ili, Вы писали:
ili>да про одно и тоже, но по ходу чего-то друг друга недопонимаем. ili>поделюсь про свой опыт.
Обожаю чужой опыт! Спасибо!
ili>SqlQuery я тупо подпилил, так что бы для SelectAll генерился запрос "SELECT * FROM [Table]" ili>плюс сделал "SelectAllOfType" — он генерит "SELECT * FROM [Table] WHERE [Type] = @type" ili>инсерты/апдейты/делиты не трогал. ili>итого, если не считать, что пользуется "*" вместо перечисления полей, и одно служебное (и вправду нафиг не сдавшееся) поле с идентификатором типа, все арбайтен.
А, ну тогда понятно!
Просто я идеалист недобитый Хотел, чтобы все красиво было.
Придется, по крайней мере пока, тоже подпилить...
Но, все-таки, было бы здорово (взываю к отцам основателям), если бы можно было указать для SqlQuery, атрибутами класса, какие поля дополнительно включать в текст SELECT помимо замапленых, плюс для ObjectFactory предусмотреть возможность указать прямо в атрибуте имя поля по которому выбирается тип создаваемого объекта.
Здравствуйте, albenik, Вы писали:
A>Здравствуйте, ili, Вы писали:
A>Но, все-таки, было бы здорово (взываю к отцам основателям), если бы можно было указать для SqlQuery, атрибутами класса, какие поля дополнительно включать в текст SELECT помимо замапленых, плюс для ObjectFactory предусмотреть возможность указать прямо в атрибуте имя поля по которому выбирается тип создаваемого объекта.
ИМХО це не типовое решение, работат только при конкретных условиях.
так что ручками
вообще, ИМХО, SqlQuery как-то не очень хорошо расширяем =\ ну как-то неудобно его допиливать...
вот сейчас IT что-то там с линком ваяет, думаю, это будет более мощный и удобный инструмент, посмотрим...
Здравствуйте, ili, Вы писали:
ili>ИМХО це не типовое решение, работат только при конкретных условиях. ili>так что ручками
ili>вообще, ИМХО, SqlQuery как-то не очень хорошо расширяем =\ ну как-то неудобно его допиливать...
Ну некоторые вещи я бы там конечно на свой вкус переписал, но это хорошо на готовенькое придти и говорить поэтому не буду
А так я его расширяю потихоньку под свои нужды.
Кстати я таки прикрутил возможность работы с ObjectFactory через SqlQuery, не знаю красиво или нет, но мне пока нравиться.
(см. вложения)
ili>вот сейчас IT что-то там с линком ваяет, думаю, это будет более мощный и удобный инструмент, посмотрим...
Линк жду с нетерпением.
Здравствуйте, albenik, Вы писали:
A>Ну некоторые вещи я бы там конечно на свой вкус переписал, но это хорошо на готовенькое придти и говорить поэтому не буду A>А так я его расширяю потихоньку под свои нужды.
где-то, когда-то IT писал, что на генерацию запросов особо BLT и не нацеливался.
с др. стороны, тогоже базового функционала SqlQuery мне, лично, хватает на 80%
Здравствуйте, ili, Вы писали:
ili>где-то, когда-то IT писал, что на генерацию запросов особо BLT и не нацеливался.
Угу, по-моему я тоже где-то на это его заявление натыкался.
Только тогда не совсем понятно, что будет делать в BLToolkit'е линк когда его прикрутят.
Если получать объекты из базы, то по-любому запросы генерировать придется.
ili>с др. стороны, тогоже базового функционала SqlQuery мне, лично, хватает на 80%
а мне теперь, хватает на 100%, когда я убедился, что могу спокойно унаследоваться и без проблем заточить наследника под себя.
Здравствуйте, albenik, Вы писали:
A>Угу, по-моему я тоже где-то на это его заявление натыкался. A>Только тогда не совсем понятно, что будет делать в BLToolkit'е линк когда его прикрутят. A>Если получать объекты из базы, то по-любому запросы генерировать придется.
покамест комметнарии Игоря были крайне туманны (по крайней мере для меня)... ждемс...
A>а мне теперь, хватает на 100%, когда я убедился, что могу спокойно унаследоваться и без проблем заточить наследника под себя.
вроде как, он синтетический, а из вашего примера ну ничего не ясно... так например, откуда в кортеже возмется колонка PersonType?
