Построение гибкого параметризованного adhoc-запроса с C #, SQL

Question

Я нахожусь в процессе создания возможности для пользователя выполнять специальные запросы к базе данных SQL Server. Результирующий запрос примет следующую базовую форму:

SELECT <ONE TO MANY USER SELECTED FIELDS>
FROM <ONE TO MANY TABLES DETERMINED BY FIELDS SELECTED BY USER>
WHERE <ZERO TO MANY CRITERIA FOR THE SELECTED FIELDS>

Это гарантия того, что выбор, скорее всего, охватит более одной таблицы. Некоторые (не все) поля могут иметь 0 или более критериев фильтра для определенного поля.

Мое приложение использует классы EF4 по умолчанию в ASP.NET MVC 2 с использованием C #. В настоящее время я передаю объект с именем QueryItem, который содержит всю информацию по определенным критериям.

Мои вопросы:

1. Каков наилучший подход для кодирования этого? (Образцы кода того, что я должен датировать ниже).
2. Можно ли это сделать с помощью Linq2SQL или использовать ADO.NET (мой текущий подход)
3. Если ADO.NET - лучший способ, как вы получаете доступ к DBConnection в EF4?

Примечание. Я намерен преобразовать это в объекты SQLParameter для защиты от внедрения SQL. В настоящее время моей целью является наилучшая практика при разработке запроса в первую очередь.

Класс QueryItem:

public class QueryItem
{
    public bool IsIncluded { get; set; }
    public bool IsRequired { get; set; }

    public string LabelText { get; set; }
    public string DatabaseLoc { get; set; }
    public List<string> SelectedValue { get; set; }

    public List<SelectListItem> SelectList { get; set; }
}

Код разбора запроса

    foreach(QueryItem qi in viewModel.StandardQueryItems)
    {
        string[] dLoc = qi.DatabaseLoc.Split(new Char[] { '.' }); //Split the table.fieldname value into a string array

        if(qi.IsIncluded == true) //Check if the field is marked for inclusion in the final query
        {
            fields.Append(qi.DatabaseLoc + ","); //Append table.fieldname to SELECT statement

            if(!tables.ToString().Contains(dLoc[0])) // Confirm that the table name has not already been added to the FROM statement
            {
                tables.Append(dLoc[0] + ","); //Append the table value to the FROM statement
            }
        }

        if(qi.SelectedValue != null)
        {
            if(qi.SelectedValue.Count == 1)
            {
                query.Append(qi.DatabaseLoc + " = '" + qi.SelectedValue[0].ToString() + "'");
            }
            else 
            {
                foreach(string s in qi.SelectedValue)
                {
                    //Needs to handle "IN" case properly
                    query.Append(qi.DatabaseLoc + " IN " + qi.SelectedValue.ToString());
                }
            }
        }
    }

Answer 1

Я создал систему, аналогичную той, которую вы описывали в прошлом, передавая один параметр хранимой процедуре типа xml.Таким образом, вы можете указать (в xml), что вы хотите отчитываться, и создать SQL, необходимый для получения желаемых результатов.

Это также делает ваш код на C # проще, так как всевам нужно сгенерировать xml, который будет читать ваша процедура.Генерирование динамического SQL - определенно не то, что вы должны использовать, если вам не нужно, но когда вы хотите позволить пользователям динамически выбирать то, о чем они хотят сообщать, это практически единственный способ сделать это.

Другим вариантом для вас может быть поиск в службах Reporting Services - это позволит пользователю выбрать, какие поля он хочет просмотреть, и сохранить этот конкретный «отчет» в своем собственном разделе, где он может затем вернуться и запустить его в любое время.. Вы также можете создавать отчеты для них, если они не разбираются в компьютерах (что гораздо проще сделать с помощью построителя отчетов, при условии, что все, что им нужно, это данные и никаких специальных функций).

В любом случаевы идете по этому поводу, их плюсы и минусы для обоих решений. Вы должны будете определить, какой вариант лучше для вас.

xml / dynamic sql: сложно поддерживать / вносить изменения.извините всех, кто должен прийти за кем-то, кто генерирует динамический SQL и попытаться понять логику беспорядка).

службы отчетов: очень легко выкладывать отчеты, которые выглядят хорошо, но они немного менее гибки и не бесплатны.