Что самый изящный путь состоит в том, чтобы использовать хранимые процедуры?

Захватите копию Библиотеки Предприятия. Это - хорошая обертка вокруг ADO. Например:

using System.Data.Common;
using System.Globalization;
using Microsoft.Practices.EnterpriseLibrary.Data;

Database db = DatabaseFactory.CreateDatabase(DatabaseType.MyDatabase.ToString());

using (DbCommand dbCommand = db.GetStoredProcCommand("dbo.MyStoredProc")) {
    db.AddInParameter(dbCommand, "identity", DbType.Int32, item.Identity);
    db.AddInParameter(dbCommand, "name", DbType.String, item.Name);
    db.AddInParameter(dbCommand, "desc", DbType.String, item.Description);
    db.AddInParameter(dbCommand, "title", DbType.String, item.Title);

    db.ExecuteNonQuery(dbCommand);
} // using dbCommand

Я обычно использую некоторое изменение следующего примера, в зависимости от среды, конечно:

Мои основные вспомогательные методы, которые я называю всюду по своему коду

public static SqlCommand CreateStoredProcCmd(string name, SqlConnection con)
{
    var cmd = new SqlCommand(name, con);
    cmd.CommandType = CommandType.StoredProcedure;
    return cmd;
}

public static void AddParams(this SqlCommand cmdObject, Params SqlParameter[] parameters)
{
  foreach(SqlParameter param in parameters)
  {
    cmdObject.Parameters.add(param);
  }
}

/* Any overloaded methods to create params receiving my param definitions 
in any manner that the usual new SqlParameter() constructor doesn't handle */
public static SqlParameter CreateSqlParam(string ParamName,
                                          SqlDbType ParamType,
                                          object value)
{
    return CreateSqlParam(ParamName, ParamType, ParameterDirection.Input, value);
}

public static SqlParameter CreateSqlParam(string ParamName, 
                                          SqlDbType ParamType, 
                                          ParameterDirection ParamDir)
{
    return CreateSqlParam(ParamName, ParamType, ParamDir, null;
}                          

public static SqlParameter CreateSqlParam(string ParamName, 
                                          SqlDbType ParamType, 
                                          ParameterDirection ParamDir,
                                          object value)
{
    var parm = new SqlParameter(ParamName, ParamType);
    parm.Direction = ParamDir;
    parm.Value = value;
    return parm;
}

Теперь вот то, как я настроил свой сохраненный procs и добавляю все мои параметры изящно

public static string DoStuff()
{
    using (var oCon = new SqlConnection("MyConnectionString"))
    {
        oCon.Open();
        var oCmd = CreateStoredProcCmd("sp_Name", oCon).AddParams(
            CreateSqlParam("Param1", SqlDBType.Int, 3),
            CreateSqlParam("Param2", SqlDBType.VarChar, "Hello World"),
            CreateSqlParam("Param3", SqlDBType.VarChar, ParameterDirection.Output)
        );
        oCmd.Prepare();
        oCmd.ExecuteNonQuery();
        object outVal = oCmd.Parameters["Param3"];
        return null != outVal ? outVal.ToString() : String.Empty;
    }
}

Вы могли использовать SubSonic в качестве уровня ORM между Вашим классом и хранимыми процедурами. Вот основной пример. У Phil Haack есть хорошая статья о нем также.

В этом другом вопросе существует некоторая хорошая информация.

Править: Так как Вы обновили свой вопрос указать, что Вы не хотите использовать ORM, SubSonic не для Вас. Однако я оставлю ответ здесь для других людей, которые используют сохраненный procs. :) Необходимо также смотреть, в том, если существует даже возможность, можно использовать ее.

Я рекомендовал бы использовать объект Microsoft Application Blocks SqlHelper.

Поскольку оператор как Вы упомянул выше, я могу сделать следующее.

SqlHelper.ExecuteNonQuery(_connectionString, "MyProcName", 1, "NameValue", "Description", "Title");

В основном Помощник SQL берет несколько параметров.

1. Строка подключения для соединения с дб
2. Название хранимой процедуры
3. Массив значений параметров, в порядке, в котором они появляются в Хранимой процедуре.

Существует ОЧЕНЬ небольшой недостаток производительности с этим методом, законченным явно создание каждого параметра, но экономия времени обычно перевешивает его, так как это является настолько маленьким.

Вы могли разделить на два linecount путем получения собственного InputSqlParameter из SqlParameter и установки направления для Ввода в конструкторе.

Это позволило бы Вам записать

    cmd.Parameters.Add(new InputSqlParameter("title", item.title));
    cmd.Parameters.Add(new InputSqlParameter("property", item.property));

Это показывает шаблон и позволяет Вам установить список названий параметра и полей объекта и выполнить в параметре, добавляющем для цикла.

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

cmd.Parameters.Add("identity", SqlDBType.???).Value = item.Identity;
cmd.Parameters.Add("desc", SqlDbType.???, ?size?).Value = item.Description;
cmd.Parameters.Add("title", SqlDBType.???, ?size?).Value = item.Title;

//Output params generally don't need a value so...
cmd.Parameters.Add("someOut", SqlDBType.???).Direction = ParameterDirection.Output;

Для создания кода немного менее подробным, я всегда добавлял использование параметров

cmd.Parameters.AddWithValue("name", item.Name);
cmd.Parameters.AddWithValue("title", item.Title);
// and so on

using (var conn = new SqlConnection(ConnectionString))
using (var cmd = conn.CreateCommand())
{
    cmd.CommandText = "[dbo].[Save]";
    cmd.CommandType = CommandType.StoredProcedure;

    cmd.Parameters.Add(new SqlParameter(
        "Identity", SqlDbType.Int) { Value = item.Identity });

    cmd.Parameters.Add(new SqlParameter(
        "Name", SqlDbType.NVarChar, 50) { Value = item.Name });

    cmd.Parameters.Add(new SqlParameter(
        "Title", SqlDbType.NVarChar, 100) { Value = item.Title });

    conn.Open();
    cmd.ExecuteNonQuery();
}

Вот то, как это могло быть похожим с Lib Ent:

// Note, that you don't need to specify connection string here,
// it will be automatically taken from a configuration file
var db = DatabaseFactory.CreateDatabase();

using (var cmd = db.GetStoredProcCommand("[dbo].[Save]"))
{
    db.AddInParameter(cmd, "Identity", DbType.Int32, item.Identity);
    db.AddInParameter(cmd, "Name", DbType.String, item.Name);
    db.AddInParameter(cmd, "Title", DbType.String, item.Title);
    db.ExecuteNonQuery(cmd);
}

Можно также использовать метод SqlHelper из Библиотеки Предприятия для упрощения этого синтаксиса.

SqlHelper.ExecuteNonQuery(connectinString,
     CommandType.StoredProcedure, "[dbo].[Save]", new SqlParameter[]
         {
             new SqlParameter("Identity", item.Identity),
             new SqlParameter("Name", item.Name),
             new SqlParameter("Title", item.Title)
         }); 

Это забавно, я acutally задал этот тот же вопрос. Все еще поиск хорошего решения.

Какой ORM является лучшим при использовании Хранимых процедур

Сохраните каждый параметр для данной хранимой процедуры в "классе данных". Используйте аннотации для определения вещей как "в" или sproc параметры.

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

Немного более чистый: Имейте один класс для исходных данных и другого для выводов (даже если некоторые находятся в/). Тем путем это ясно (к клиентскому коду), в котором параметры должны быть заполнены на пути и который возвращается. Также это устраняет потребность в тех аннотациях.