ADO.NET dans .NET Core est-il possible?
J'aimerais utiliser les versions les plus récentes d'ASP.NET Core, car je souhaite créer un ensemble d'API Web avec celui-ci. Cependant, les tutoriels que j'ai trouvés sont fortement axés sur Entity Framework. Je ne peux pas l'utiliser parce que j'ai déjà une base de données "héritée", donc une approche Code-First n'est pas une option.
Mon idée est d’utiliser des connexions ADO.NET à ma base de données, mais je ne sais pas si System.Data.SqlClient est disponible dans un projet ASP.NET Core. J'ai déjà trouvé ce qui est disponible lorsque j'utilise un modèle de projet .NET Framework, mais est-il toujours disponible dans un projet .NET Core?
Le SqlConnection existant et d’autres connexions connexes existent toujours dans le System.Data.SqlClient namespace et devrait fonctionner comme prévu en utilisant le framework complet ou .NET Core.
Vous aurez juste besoin d'ajouter les références appropriées et d'utiliser des instructions pour l'inclure, par exemple à l'aide du System.Data.SqlClient espace de noms comme on le voit ci-dessous dans votre project.json fichier :
puis appelez-le via la syntaxe à laquelle vous êtes habitué:
using(var connection = new SqlConnection("{your-connection-string}"))
{
// Do work here
}
Donc, tant que vous avez une chaîne de connexion valide pour vous connecter à votre base de données existante, tout devrait bien se passer.
Concernant l'utilisation de l'ORM
J'ai également constaté que certaines personnes utilisaient Dapper, un substitut de Micro-ORM pour Entity Framework, apparemment beaucoup plus flexible. Y at-il des avantages à l’utiliser à la place de ADO.NET?
Ces ORM (mappeurs objet-relationnels) sont des outils pratiques et souvent puissants qui peuvent plus facilement mapper vos données de base de données existantes vers des classes et des objets spécifiques, ce qui peut les rendre plus faciles à utiliser (par opposition à une itération via un lecteur de données lignes et construction de chaque objet manuellement).
En ce qui concerne les performances, cela dépend en définitive de ce que vous allez faire avec vos requêtes. ADO.NET sera généralement le plus rapide car il s’agit d’une connexion directe à la base de données. Toutefois, dans certains cas, Dapper est en mesure de le vaincre. Entity Framework, bien que très utile, traîne généralement en retard sur les performances, tout simplement parce que c'est un ORM de grande taille.
Encore une fois, tout dépend de ce que vous faites, mais ce sont toutes des options viables.
.NET Core 2.0 a DataSet, DataTable et SQlDataAdapter. Voir ma réponse à l'adresse https://blogs.msdn.Microsoft.com/devfish/2017/05/15/exploring-datatable-and-sqldbadapter-in-asp-net-core-2-0/ =.
Le code ci-dessous fonctionne bien
public static DataTable ExecuteDataTableSqlDA(SqlConnection conn, CommandType cmdType, string cmdText, SqlParameter[] cmdParms)
{
System.Data.DataTable dt = new DataTable();
System.Data.SqlClient.SqlDataAdapter da = new SqlDataAdapter(cmdText, conn);
da.Fill(dt);
return dt;
}
Il est important de noter que .NET Core n'a pas DataSet, DataTable et les objets associés antérieurs à la version 2.0. Mais avant la version 2.0, il disposait de toutes les fonctionnalités essentielles telles que Connexion, Commande, Paramètre, DataReader et d’autres objets connexes.
Vous pouvez utiliser les appels suivants pour simplifier la connectivité à SQL Server via le fournisseur de base de données SQL Server.
public class BaseDataAccess
{
protected string ConnectionString { get; set; }
public BaseDataAccess()
{
}
public BaseDataAccess(string connectionString)
{
this.ConnectionString = connectionString;
}
private SqlConnection GetConnection()
{
SqlConnection connection = new SqlConnection(this.ConnectionString);
if (connection.State != ConnectionState.Open)
connection.Open();
return connection;
}
protected DbCommand GetCommand(DbConnection connection, string commandText, CommandType commandType)
{
SqlCommand command = new SqlCommand(commandText, connection as SqlConnection);
command.CommandType = commandType;
return command;
}
protected SqlParameter GetParameter(string parameter, object value)
{
SqlParameter parameterObject = new SqlParameter(parameter, value != null ? value : DBNull.Value);
parameterObject.Direction = ParameterDirection.Input;
return parameterObject;
}
protected SqlParameter GetParameterOut(string parameter, SqlDbType type, object value = null, ParameterDirection parameterDirection = ParameterDirection.InputOutput)
{
SqlParameter parameterObject = new SqlParameter(parameter, type); ;
if (type == SqlDbType.NVarChar || type == SqlDbType.VarChar || type == SqlDbType.NText || type == SqlDbType.Text)
{
parameterObject.Size = -1;
}
parameterObject.Direction = parameterDirection;
if (value != null)
{
parameterObject.Value = value;
}
else
{
parameterObject.Value = DBNull.Value;
}
return parameterObject;
}
protected int ExecuteNonQuery(string procedureName, List<DbParameter> parameters, CommandType commandType = CommandType.StoredProcedure)
{
int returnValue = -1;
try
{
using (SqlConnection connection = this.GetConnection())
{
DbCommand cmd = this.GetCommand(connection, procedureName, commandType);
if (parameters != null && parameters.Count > 0)
{
cmd.Parameters.AddRange(parameters.ToArray());
}
returnValue = cmd.ExecuteNonQuery();
}
}
catch (Exception ex)
{
//LogException("Failed to ExecuteNonQuery for " + procedureName, ex, parameters);
throw;
}
return returnValue;
}
protected object ExecuteScalar(string procedureName, List<SqlParameter> parameters)
{
object returnValue = null;
try
{
using (DbConnection connection = this.GetConnection())
{
DbCommand cmd = this.GetCommand(connection, procedureName, CommandType.StoredProcedure);
if (parameters != null && parameters.Count > 0)
{
cmd.Parameters.AddRange(parameters.ToArray());
}
returnValue = cmd.ExecuteScalar();
}
}
catch (Exception ex)
{
//LogException("Failed to ExecuteScalar for " + procedureName, ex, parameters);
throw;
}
return returnValue;
}
protected DbDataReader GetDataReader(string procedureName, List<DbParameter> parameters, CommandType commandType = CommandType.StoredProcedure)
{
DbDataReader ds;
try
{
DbConnection connection = this.GetConnection();
{
DbCommand cmd = this.GetCommand(connection, procedureName, commandType);
if (parameters != null && parameters.Count > 0)
{
cmd.Parameters.AddRange(parameters.ToArray());
}
ds = cmd.ExecuteReader(CommandBehavior.CloseConnection);
}
}
catch (Exception ex)
{
//LogException("Failed to GetDataReader for " + procedureName, ex, parameters);
throw;
}
return ds;
}
}
Veuillez vous reporter à l'article suivant pour plus de détails et d'exemples: http://www.ijz.today/2016/09/net-core-10-connecting-sql-server.html
Comme Joe Healy l'a mentionné dans son réponse dans DotNet Core 2.0, il est possible d'utiliser toutes les fonctionnalités de System.Data.
Ajouter des pépites:
- Microsoft.Extensions.Configuration
- Microsoft.Extensions.Configuration.Json - Pour lire la chaîne de connexion à partir de json
- System.Data.Common
- System.Data.SqlClient
exemple config.json:
{
"connectionString": "your-db-connection-settings"
}
Voici un exemple d'application de console complète.
class Program
{
static void Main(string[] args)
{
var configuration = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("config.json", false)
.Build();
var connectionString = configuration.GetSection("connectionString").Value;
if(string.IsNullOrEmpty(connectionString))
throw new ArgumentException("No connection string in config.json");
using (var conn = new SqlConnection(connectionString))
{
var sql = "SELECT * FROM ExampleTable";
using (var cmd = new SqlCommand(sql, conn))
{
using (var adapter = new SqlDataAdapter(cmd))
{
var resultTable = new DataTable();
adapter.Fill(resultTable);
}
}
}
}
}
Dans ADO.NET Core, je n’utilise PAS System.Data.SqlClient mais j’utilise Microsoft.Data.SqlClient. Jusqu'à présent, je pouvais utiliser tous mes codages précédents !.