Comments 5
Интересная работа, но решение полностью завязано на работу с хранимыми процедурами.
А IL-генерация кода позволяет повысить производительность или зачем?
А IL-генерация кода позволяет повысить производительность или зачем?
Спасибо большое.
В принципе, возможность работы без хранимых процедур появляется, если добавить в класс DataManager следующий код:
Я не стал вносить его в код класса изначально, потому что сам использую только хранимые процедуры, а так же меня смущает следующая тонкость:
Если посмотреть на код маппера, Вы увидите, что хэшкод текста команды весьма важен — он используется для определения (при повторном обращении), необходимо ли снова генерировать IL, инициализирующий экземляр класса результатами работы запроса. Если для хранимой процедуры можно согласиться, что процедуры с разными именами по разному инициализируют поля объекта, то для текста SQL запроса, основываясь лишь на его хэш, этого не определить. То есть для каждого запроса, даже если они выбирают одни и те же столбцы, но различаются телом, будет генерироваться свой IL код. Еще раз повторюсь, генерация будет производится единожды для данного запроса и мэппируемого ему типа.
По второму пункту — так точно, IL-генерация позволяет повысить производительность. Конечно же, там нет никаких проверок, потому приходится быть очень внимательным при описании модели и процедур.
В принципе, возможность работы без хранимых процедур появляется, если добавить в класс DataManager следующий код:
public DataManager Sql(string cmdText)
{
this.command = this.connection.CreateCommand();
this.command.CommandText = cmdText;
this.command.CommandType = CommandType.Text;
this.cmdHashCode = cmdText.GetHashCode();
return this;
}
Я не стал вносить его в код класса изначально, потому что сам использую только хранимые процедуры, а так же меня смущает следующая тонкость:
Если посмотреть на код маппера, Вы увидите, что хэшкод текста команды весьма важен — он используется для определения (при повторном обращении), необходимо ли снова генерировать IL, инициализирующий экземляр класса результатами работы запроса. Если для хранимой процедуры можно согласиться, что процедуры с разными именами по разному инициализируют поля объекта, то для текста SQL запроса, основываясь лишь на его хэш, этого не определить. То есть для каждого запроса, даже если они выбирают одни и те же столбцы, но различаются телом, будет генерироваться свой IL код. Еще раз повторюсь, генерация будет производится единожды для данного запроса и мэппируемого ему типа.
По второму пункту — так точно, IL-генерация позволяет повысить производительность. Конечно же, там нет никаких проверок, потому приходится быть очень внимательным при описании модели и процедур.
А Table Valued параметры поддерживаются?
Спасибо. Почти что «ни прибавить, ни убавить», кроме разве что Stored Procedures [LINQ to SQL], ибо LINQ — это определённо лучше, чем SQL, в плане того, что код перестаёт быть неоднородным. Хотя есть вероятность, что упадёт производительность, но речь же, я надеюсь, не о хайлоад проекте, чтобы думать об этом настолько. Если хайлоад, то желателен вообще нативный C++ и никакого шарпа.
Sign up to leave a comment.
Микро-ORM одним классом