Which is a better approach to pass data to procedures?

Id's say make an object to centralize data access (as such can more easily be tested and mocked out in unit tests) and in that one have your average parameter checking, escape sequence checking and then pass as parameter and you should bee sort of belt and suspenders and can optimize your data connections usage etc.

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

a nice addon is to check your string type parameters for escape sequence like the simplified one below ... you don't really want odd exceptions from parameter binding or sql ... much better to know exactly what's wrong if this thing occurs

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;
        }

As an alternative consider using a repository framework like entity framework, this will take care of parameter handling for you and you cannot avoid doing it right so to say ;)

The only correct answer is, "it depends". :)

If you're passing a single set of values to a stored procedure, then it's usually better to pass individual parameters. The only time you'd need a different solution would be if you needed to pass more than the maximum number of parameters allowed. But since that limit is 2100 per procedure, if you ever reach it, you urgently need to re-evaluate your database design!

If you're passing multiple values to a stored procedure, you have several options:

• For lists of numbers, you might be able to pass them as a single delimited string, and use STRING_SPLIT[^] or a custom string splitting function to extract the list of values;
• You can use an XML parameter, with the values stored as child elements:
  Using XML to pass lists as parameters in SQL Server - Simple Talk[^]
  As that article shows, the performance degrades quite rapidly for large lists.
• If you're using SQL Server 2008 or later, you can use a Table Valued Parameter:
  Table-Valued Parameters | Microsoft Docs[^]
  Using SQL Server's Table Valued Parameters - Brent Ozar Unlimited®[^]