Здравствуйте, IT, Вы писали:
IT>На BLToolkit это будет выглядеть примерно следующим образом:
Спасибо за ответ!
Тогда ещё несколько вопросов, пока вы добрый.
1. у меня лежит скачанная версия 3.2 с середины прошлого года. А сейчас финальная опубликованная версия — 3.1. Проект жив?
2. я правильно понял, что Linq AST рендерится в SqlQuery, а потом уже он рендерится в настоящий Sql запрос?
3. счас обнаружил, что SqlQuery существует разный в папках Data\Sql и DataAccess. И они оба (точнее используемые ими SqlQueryBase и разные Clause'ы соот-но) занимаются генерацией запросов. Что-то из них устаревшее или оба в силе?
4. Можно ли где почитать про концептуальное устройство библиотеки? Т.е. там же всё разделено вроде бы — сбор информации о запросе, трансформации, генерация sql, выполнение запроса, получение результатов, маппинг. К тому же по приведённому вами примеру я так понимаю, что в основе лежит нетипизированый доступ к данным, а уже на уровне выше (ближе к юзеру) он может типизироваться. Но читая код я вижу, что маппинг, чтение метаданных и генерация запроса идут как будто в одном месте:
protected SqlQueryInfo CreateInsertSqlText(DbManager db, Type type, int nParameter)
{
TypeExtension typeExt = TypeExtension.GetTypeExtension(type, Extensions);
ObjectMapper om = db.MappingSchema.GetObjectMapper(type);
List<MemberMapper> list = new List<MemberMapper>();
StringBuilder sb = new StringBuilder();
SqlQueryInfo query = new SqlQueryInfo(om);
MetadataProviderBase mp = MappingSchema.MetadataProvider;
sb.Append("INSERT INTO ");
AppendTableName(sb, db, type);
sb.Append(" (\n");
foreach (MemberMapper mm in GetFieldList(om))
{
// IT: This works incorrectly for complex mappers.
//
// [2009-03-24] ili: use mm.MemberAccessor instead of mm.ComplexMemberAccessor
// as in CreateUpdateSqlText
//
bool isSet;
if (mp.GetNonUpdatableAttribute(type, typeExt, mm.MapMemberInfo.MemberAccessor, out isSet) == null || !isSet)
{
sb.AppendFormat("\t{0},\n",
db.DataProvider.Convert(mm.Name, ConvertType.NameToQueryField));
list.Add(mm);
}
}
это сильно сбивает с толку (вероятно, в большей степени из-за того, что ожидаю увидеть так как сам себе это представлял). Хотелось бы понять концепции — ключевые ответственности, интерфейсы, классы; как они между собой взаимосвязаны. Чтобы когда уже полез в код, не удивляться.
5. Есть ли в планах растащить всё по разным сборкам? Чтобы было проще понимать и использовать только то, что надо? Например, мне нравится модель маппирования BLT и я хочу её использовать, но то, что надо тащить ещё целый паровозик доступа к данным — это пугает. Хотя я подозреваю, что люди делятся на два типа — кому нравится иметь всё в разных сборках и кто любит всё в одном, поэтому может это и спорное решение, но конкретные планы этого проекта всё же интересны.