knackCoder Ответов: 3

Какой подход лучше подходит для передачи данных процедурам?


Были случаи, когда я передавал данные процедурам в виде различных параметров, и даже я передавал данные процедуре, создавая один XML-параметр для отправки в процедуру целых данных.

Поэтому я хочу знать, какой подход лучше подходит для передачи данных в процедуру среди "передачи различных параметров по-разному" или "передачи данных в виде одного XML-элемента"?;
Ситуации, когда передача данных в виде XML дает преимущество перед передачей параметров?

Что я уже пробовал:

Какой подход лучше подходит для передачи данных в процедуру среди "передачи различных параметров по-разному "или"передачи данных в виде одного XML-элемента"?;
Ситуации, когда передача данных в виде XML дает преимущество перед передачей параметров?

Thomas Nielsen - getCore

Что это за процедуры? Есть ли у вас мужчины в C#, так называемые методы классов? или хранимые процедуры SQL? или RPC вне отсека резьбы, как к другому процессу или машине?

knackCoder

Я имею в виду хранимые процедуры SQL.

3 Ответов

Рейтинг:
2

Thomas Nielsen - getCore

Id, скажем, делает объект для централизации доступа к данным (как таковой может быть более легко протестирован и высмеян в модульных тестах), и в этом случае у вас есть ваша средняя проверка параметров, проверка escape-последовательности, а затем передать в качестве параметра, и вы должны быть своего рода поясом и подтяжками и можете оптимизировать использование ваших подключений к данным и т. д.

using (var cn = GetConnection())
        {
            using(var cmd = new SqlCommand("spMyProcedure", cn))
            {
                cmd.CommandType = System.Data.CommandType.StoredProcedure;
                cmd.Parameters.AddWithValue("@id", invoiceNumber);
                cmd.Parameters.AddWithValue("@comment", FlareOnBadChars(comment));
                cmd.Parameters.AddWithValue("@note", FlareOnBadChars(note));
                var affect = (int)cmd.ExecuteScalar();

                if (affect != 1)
                    throw new DataConcernsException(string.Format("Expected to insert data but failed with data: '{0}','{1}','{2}'", invoiceNumber, comment, note));
            }
        } //Implicitly dispose already calls close on your connection


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

private string FlareOnBadChars(string source)
       {
           if (!Regex.IsMatch(source, @"\A[^\\]+\Z"))  //TODO: add other things that you don't like before the ]
               throw new DataConcernsException("That's not a nice string");
           return source;
        }



В качестве альтернативы рассмотрите возможность использования структуры репозитория, такой как entity framework, это позаботится об обработке параметров для вас, и вы не можете избежать того, чтобы сделать это правильно, так сказать ;)


Graeme_Grant

"можно ли легче протестировать и высмеять в модульных тестах" - неужели вы действительно думаете, что он может это сделать, учитывая этот вопрос?

Thomas Nielsen - getCore

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

Graeme_Grant

;)

Рейтинг:
2

Richard Deeming

Единственный правильный ответ: "это зависит". :)

Если вы передаете один набор значений хранимой процедуре, то обычно лучше передавать отдельные параметры. Единственное время, когда вам понадобится другое решение, - это если вам нужно будет передать больше, чем максимально допустимое количество параметров. Но так как этот предел 2100 согласно процедуре, если вы когда-нибудь достигнете ее, вам срочно нужно будет пересмотреть дизайн вашей базы данных!

Если вы передаете несколько значений хранимой процедуре, у вас есть несколько вариантов:


Рейтинг:
0

Graeme_Grant

Цитата:
Я хочу знать, какой подход лучше подходит для передачи данных в процедуру

SQL? Как параметры, которых следует избегать SQL-инъекция[^].