SQL Server: Динамический где-пункт
Вопрос 1: Модель зависит от того, кто «работает» с данными. Слой персистентности с O / R mapper имеет определенный способ моделирования объектов (или, если быть точным: классы). С другой стороны: представление в браузере (не в БД) обычно смешивает данные из разных объектов, поэтому вы создаете настраиваемый DTO для этого представления, содержащего именно то, что нужно отображать в этом представлении. Это также включает в себя не показывать данные, которые не требуются представлением, и избегать множественных запросов (сначала этот объект, затем тот ...). Если необходимы дальнейшие преобразования, необходимо решить, требуется ли кому-то другая структура данных. Я думаю, что это не обычный случай использования, обычно вы должны отобразить структуры данных из БД на требуемые данные представления.
Вопрос 2. Если ваша служба доступности только проверяет наличие, она не должна бронировать. В противном случае имя будет ложным. В Варианте 2 неверно указано имя контроллера, это, очевидно, не Контроллер доступности, а что-то вроде OrderController, следует помнить о выборе хороших имен (Чистый код).
3 ответа
У Вас есть две опции. При использовании SQL Server 2008 (или Oracle), можно передать в параметре, передаваемом по значению таблицы.
При использовании SQL Server 2005 можно использовать XML для моделирования этой возможности
При использовании чего-то ранее, чем 2005 необходимо связать идентификаторы в единственной строке и создать UDF для парсинга их.
Вы могли, по крайней мере, параметризовать где clausule для предотвращения Внедрения SQL, что-то одинаково:
using System.Data;
using System.Data.SqlClient;
using System.Text;
class Foo
{
public static void Main ()
{
string[] parameters = {"salt", "water", "flower"};
SqlConnection connection = new SqlConnection ();
SqlCommand command = connection.CreateCommand ();
StringBuilder where = new StringBuilder ();
for (int i = 0; i < parametes.Length; i++)
{
if (i != 0)
where.Append (",");
where.AppendFormat ("@Param{0}", i);
command.Parameters.Add (new SqlParameter ("Param" + i, parameters [i]));
}
}
}
В зависимости от того, как Вы обрабатываете входные компоненты, я думаю, что этот существующий метод имеет некоторые риски внедрения SQL.
Вы могли добавить имя компонента к условиям объединения, которые могут быть более быстрыми.
Вы могли также хешировать комбинации ингредиентов для receipes для быстрого поиска.