Usando ASP.Net MVC con Classic ADO.Net

Estoy buscando una forma de acceder a los procedimientos almacenados utilizando Classic ADO.Net, ya que soy nuevo en ASP.Net MVC. No sé cómo hacerlo.

La mayoría de los ejemplos muestran operaciones CRUD utilizando el marco de Entidad ADO.Net.

Podrías tener un repository:

public interface IUsersRepository { public User GetUser(int id); } 

luego implementarlo:

 public class UsersRepository: IUsersRepository { private readonly string _connectionString; public UsersRepository(string connectionString) { _connectionString = connectionString; } public User GetUser(int id) { // Here you are free to do whatever data access code you like // You can invoke direct SQL queries, stored procedures, whatever using (var conn = new SqlConnection(_connectionString)) using (var cmd = conn.CreateCommand()) { conn.Open(); cmd.CommandText = "SELECT id, name FROM users WHERE id = @id"; cmd.Parameters.AddWithValue("@id", id); using (var reader = cmd.ExecuteReader()) { if (!reader.Read()) { return null; } return new User { Id = reader.GetInt32(reader.GetOrdinal("id")), Name = reader.GetString(reader.GetOrdinal("name")), } } } } } 

y luego su controlador podría usar este repository:

 public class UsersController: Controller { private readonly IUsersRepository _repository; public UsersController(IUsersRepository repository) { _repository = repository; } public ActionResult Index(int id) { var model = _repository.GetUser(id); return View(model); } } 

De esta forma, el controlador ya no dependerá de la implementación de su capa de acceso a datos: ya sea que use ADO.NET simple, NHibernate, EF, algún otro ORM, llame a un servicio web externo, XML, lo que usted prefiera.

Ahora todo lo que queda es configurar su marco de DI favorito para inyectar la implementación adecuada del repository en el controlador. Si mañana decide cambiar su tecnología de acceso a datos, no hay problema, simplemente escriba una implementación diferente de la interfaz IUsersRepository y reconfigure su marco DI para usarlo. No es necesario tocar la lógica de tu controlador.

Su aplicación MVC ya no está vinculada a la forma en que se almacenan los datos. Esto hace que sea más fácil probar sus controladores en forma aislada ya que ya no están estrechamente acoplados a una fuente de datos particular.

Echa un vistazo a Dapper-dot-net : es lo que impulsa este sitio: excelente, liviano, basado en ADO.NET puro, compatible con procedimientos almacenados muy bien, ¡no puedo decir suficientes cosas buenas sobre él!

ASP.NET MVC funciona con cualquier marco de base de datos que desee utilizar. Puede recuperar sus datos de la forma que prefiera (como ADO.NET clásico) y pasar el modelo de datos resultante a la vista. Solo tiene que especificar el tipo de modelo en la Vista para que coincida con el objeto que le está pasando.

Si sabe cómo hacerlo con ADO.NET, puede hacerlo en ASP.NET MVC (tenga en cuenta que estos marcos son completamente diferentes y no dependen entre sí).

Puede encapsular su código de DataAccess en Repositorios y usar esos Repositorios, en Controladores;