Re[7]: BLToolkit как инструмент генерации SQL
От: Neco  
Дата: 15.03.11 17:31
Оценка:
Здравствуйте, 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 и я хочу её использовать, но то, что надо тащить ещё целый паровозик доступа к данным — это пугает. Хотя я подозреваю, что люди делятся на два типа — кому нравится иметь всё в разных сборках и кто любит всё в одном, поэтому может это и спорное решение, но конкретные планы этого проекта всё же интересны.
всю ночь не ем, весь день не сплю — устаю
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.