I'm building my first web app with .net, and it needs to interact with a very large existing database. I have the connection set up, and have made a class that I can call to build select, insert, update and delete queries passing in several parameters.
I can connect by writing the query I want in the button click, but I want to know is this the best solution? It seems hard to debug this way, as it is mixing the database code with other code.
In the past (in other languages) I have created a class which would contain all of the database query strings and parameters which would be called by the rest of the code. That way if something simple like the stored procedure parameters change, the code is all in one place.
When I look for this in .net, I see nothing about doing it this way and I'm keen to learn the best practices.
protected void Button1_Click(object sender, EventArgs e)
{
NameLabel.Text = UserNoTextBox.Text;
string spName = "SP_SelectUser";
SqlParameter[] parameters = new SqlParameter[]
{
new SqlParameter("#User_No", UserNoTextBox.Text)
};
DataAccess dbAccess = new DataAccess();
DataTable retVal = dbAccess.ExecuteParamerizedSelectCommand(spName, CommandType.StoredProcedure, parameters);
}
Update: The class I was referring to was the DataAccess class from the following website:
http://www.codeproject.com/Articles/361579/A-Beginners-Tutorial-for-Understanding-ADO-NET
(Class available at http://www.codeproject.com/script/Articles/ViewDownloads.aspx?aid=361579)
Update: In the end I opted for using MVC 3 with Entity Framework - it's great!
This is a huge topic, but a very brief view might be as follows:
DataTable must die (ok, it has a few uses, but in general: it must die); consider using a custom type such as:
public class User {
public int Id {get;set;}
public string Name {get;set;}
public string EmployeeNumber {get;set;}
// etc
}
It should also be noted that many ORM tools will generate these for you from the underlying table structure.
don't mix UI and data access; separate this code, ideally into separate classes, but at the minimum into separate methods:
protected void Button1_Click(object sender, EventArgs e)
{
NameLabel.Text = UserNoTextBox.Text;
var user = SomeType.GetUser(UserNoTextBox.Text);
// do something with user
}
...
public User GetUser(string userNumber) {
... your DB code here
}
use a library such as an ORM (EF, LINQ-to-SQL, LLBLGenPro) or a micro-ORM (dapper, PetaPoco, etc) - for example, here's that code with dapper:
public User GetUser(string userNumber) {
using(var conn = GetOpenConnection()) {
return conn.Query<User>("SP_SelectUser",
new {User_No = userNumber}, // <=== parameters made simple
commandType: CommandType.StoredProcedure).FirstOrDefault()
}
}
or with LINQ-to-SQL (EF is very similar):
public User GetUser(string userNumber) {
using(var db = GetDataContext()) {
return db.Users.FirstOrDefault(u => u.User_No == userNumber);
}
}
not everything needs to be a stored procedure; there used to be a huge performance difference between the two - but that is no longer the case. There are valid reasons to use them (very granular security, shared DB with multiple application consumers, a dba who thinks they are a developer), but they also create maintenance problems, especially when deploying changes. In most cases I would not hesitate to use raw (but parameterized) SQL, for example:
public User GetUser(string userNumber) {
using(var conn = GetOpenConnection()) {
return conn.Query<User>(#"
select [some columns here]
from Users where User_No = #userNumber",
new {userNumber}).FirstOrDefault()
}
}
I would do something like this:
code behind
protected void Button1_Click(object sender, EventArgs e)
{
UserController uc = new UserController();
User u = UserController.GetUser(Convert.ToInt32(UserNoTextBox.Text);
NameLabel.Text = u.UserName;
}
And in your UserController.cs
class UserController{
public User GetUser(int userId)
{
return DataAccess.GetUser(userId);
}
}
And in your User.cs
class User{
private string _userName;
public string UserName{ get{ return _userName;} set{ _userName= value;} }
}
And in your DataAccess.cs using Dapper
public User GetUser(int id)
{
var user = cnn.Query<User>("SP_SelectUser", new {User_No = id},
commandType: CommandType.StoredProcedure).First();
return user;
}
This is just one option, but you can also use different ORM's
It is about personal flavor. Here is a list of .Net ORM's
Good luck!
General best practices tend to be language agnostic in the OOP world. You say you have worked with data access in other OOP languages in the past, so would do exactly the same in .net. See response from #Oded for good links for general best practices.
If you are looking for guidance on how best to use .net's data access technology, try MSDN's articles on ADO as a starting point.
What you are doing will work, but doesn't follow good OOP principles, one of which is separation of concerns - your UI shouldn't be talking to the database directly.
You should have all your data access code placed in a separate layer which your UI layer can call.
Also see the SOLID principles and Don't repeat yourself.
When interacting with the database, many people use an ORM - Entity Framework, nHibernate, Dapper and many others exist for .NET applications. These act as a data access layer and you should investigate their usage for your application.
Related
When I try to search data in my user control from my database it does search or filter the data that I typed in the search textbox. Here's the code that I'm using to try and search or filter
SqlConnection cn;
SqlCommand cm;
SqlDataReader dr;
private Label name;
private Label amount;
private Label descrip;
public Form1()
{
InitializeComponent();
cn = new SqlConnection(#"Data Source=(LocalDB)");
}
private void Form1_Load(object sender, EventArgs e)
{
GetData();
}
private void GetData()
{
cn.Open();
cm = new SqlCommand("Select * from Bills where (billname) like '%" + txtSearch.Text + "%'", cn);
dr = cm.ExecuteReader();
while (dr.Read())
{
long len = dr.GetBytes(0, 0, null, 0, 0);
byte[] array = new byte[System.Convert.ToInt32(len) + 1];
dr.GetBytes(0, 0, array, 0, System.Convert.ToInt32(len));
name = new Label();
name.Text = dr["billname"].ToString();
descrip = new Label();
descrip.Text = dr["billdescrip"].ToString();
amount = new Label();
amount.Text = dr["billamount"].ToString();
}
dr.Close();
cn.Close();
}
private void txtSearch_TextChanged(object sender, EventArgs e)
{
GetData();
}
When I type something into the txtSearch.text box, the results come back empty and doesn't display the what im trying to search for in the txtSearch.text box.
"Select * from Bills where (billname) like '%" + txtSearch.Text + "%'"
It seems to me that you have a database table Bills, with a column BillName. The operator types some text in TextBox txtSearch, and you want to fetch all Bills that have a BillName that starts with the text in the TextBox.
I see several problems here
SQL Injection
SQL injection is a code injection technique that might destroy your database.
SQL injection is one of the most common web hacking techniques.
SQL injection is the placement of malicious code in SQL statements
Look what your Sql text would be if the operator types the following text:
"John%; DROP TABLE Bills;--"
Select * from Bills where (billname) like %John%; DROP TABLE Bills; --%
You would lose all Bills!
More information about SQL Injection
Solution: Never, ever add input data into your sql string! Always add it as a parameter!
Start using using statements
The database connection is a scarce resource: you should not keep it alive longer than needed. Also, if you SQL query encounters an exception, the connection and the datareader are not closed.
Make it a habit, that whenever an object implements IDisposable you should use it using a using statement.
This way, you can be assured that whatever happens, at the end of the using statement everything is properly flushed, written, closed and disposed.
SqlConnection, SqlCommand and SqlDataReader should be private members of GetData. This way you can be certain that no one can tamper with your connection; you hide how you fetch the data from the database (SQL and SqLCommand, or Entity Framework and LINQ?), thus making future changes easier. Readers of your code won't have to check where these variables are used, and that no one is misusing it, thus making your code easier to understand. And of course this will make it possible to reuse GetData for other purposes.
Which brings me to the third improvement:
Separate data from how it is displayed
In modern programming you see more and more a separation between the date (= model) and the way that the data is displayed (= view).
Separation makes it better to reuse the code, for instance: if you want to use your model in a console program, or in a WPF program, or even a different Form, you can reuse the model classes.
Separation hides how and where you fetch your data: is it a database? is it a CSV file, or XML? are you using Entity Framework
This hiding allows future changing without having to change all your Forms
This hiding also makes your Forms smaller and easier to understand
While developing the form, you can mock the actual data: just create a dummy class that provides you with sample data, without having to bother about the database
You can unit test the model, without needing a form
It is hardly any extra work.
So you'll have Model classes: your data, and how it is saved, fetched again; and View classes: your Forms. You'll need an adapter class to adapt the model to the view: the ViewModel. Together these three abbreviate to MVVM. Consider to do some background reading about MVVM.
Implementing the three advices
We create a class that makes it possible to save Bills (and other items: Customers? Orders? Products? etc) and later you can retrieve them again, even after you restarted the program. Something like a warehouse, a repository, where you store items and fetch them again.
interface IOrderRepository
{
int AddBill(Bill bill); // return Id of the Bill
Bill FindBill(int Id); // null if not found
// your GetData:
IEnumerable<Bill> FetchBillsWithNameLike(string name);
... // other methods, about Customers, Orders, etc
}
Implementation:
class OrderRepository : IOrderRepository
{
private string ConnectionString {get;} = #"Data Source=(LocalDB)";
private IDbConnection CreateConnection()
{
return new SqlConnection(this.ConnectionString);
}
The implementation of FetchBillsWithNameLike:
public IEnumerable<Bill> FetchBillsWithNameLike(string name)
{
using (IDbConnection dbConnection = this.CreateConnection())
{
const string sqlText = "Select Id, BillName, CustomerId, ..."
+ " from Bills where (billname) like %#Name%";
using (IDbCommand = dbConnection.CreateCommand())
{
// fill the command and the parameter:
dbCommand.CommandText = sqlText;
dbCommand.AddParameterWithValue("#Name", name);
// execute the command and enumerate the result
dbConnection.Open();
using (IDatareader dbReader = dbCommand.ExecuteReader())
{
while (dbReader.Read())
{
// There is a Bill to read
Bill bill = new Bill
{
Id = dbReader.ReadInt32(0),
Name = dbReader.ReadString(1),
CustomerId = dbReader.ReadInt32(2),
...
};
yield return bill;
}
}
}
}
}
// implement rest of interface
}
Several improvements:
Connection string is a property. If you decide to use a different connection string for all your 100 methods: only one place to change.
You hide where you get the connection string: here it is a constant, but if you decide in future versions to read it from the config file: no one has to know, except this method
You hide that you are using a SqlConnection, you return the interface. If in future versions you decide to create a different form of IDbConnection, for instance for a different kind of database, like SQLite, no one has to know that you create a SqlLiteConnection object instead of a SqlConnection.
Similarly: hide SqlCommand, use the interface IDbCommand.
The database connection is not opened before it is needed. This makes it possible that others can use the database as long as you will not use it.
using statements all over the place: if any exception happens, all objects are properly closed and disposed.
I don't create the DbCommand myself, I ask the DbConnection to create it for me, so I don't have to bother which type of commands the actual DbConnection uses: Is it SqlCommand? SQLiteCommand?
I specify which columns from the table if want. If in future some columns are added, and I don't need them, I won't fetch more data than I want. Similarly: if columns are reordered, it will still work.
The most important change: Use SQL parameter to prevent malicious SQL Injection.
Parameters in SQL text are often recognized by prefix #
Parameters are added with the extension method AddParameterWithValue`. Some databases have this as a method in DbCommand (for example: SQLite)
When reading the fetched data, I won't read more Bills than my caller wants. So if he calls me using the following code: not all Bills will be read:
IOrderRepository repository = ...
string name = this.ReadName();
bool billsWithNameAvailable = repository.FetchBillsWithName(name).Any();
Here, my caller only wants to know if there are any Bills with the Name at all. The reader won't create any Bills at all.
Because the SQL text is Select Id, ... and I read dbReader.GetInt32[0] etc, my code will still work, even after inserting or reordering the columns of the table.
The nice thing is, that you will be able to unit test method FetchBillsWithName without having to use a Form: you can test what happens if there is no database at all, or if there is no Bills table, or an empty table, or the table doesn't contain a column BillName. Or what happens if the input text is empty. You can unit test all kinds of errors without need of a Form.
The Form
class Form1 : ...
{
private IOrderRepository Repository {get;} = new OrderRepository();
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
GetData();
}
private void GetData()
{
string name = this.txtSearch.Txt;
foreach(Bill fetchedBill in this.Repository.FetchBillsWithNameLike(name))
{
this.ProcessBill(fetchedBill);
}
}
private void ProcessBill(Bill fetchedBill)
{
// do your stuff with the label;
}
}
Because I separated the model from the view, the view is much simpler: much easier to see what really happens: you focus on the form, not on how and where you get the data.
During development, while you don't have a database yet, you can create a dummy repository and test your form:
class DummyRepository : IOrderRepository
{
private Dictionary<int, Bill> Bills {get;} = ... // fill with some sample Bills
// TODO: implement IOrderRepository, using this.Bills
}
If later you decide that you won't get your data from a database, but for instance from the internet, your form will hardly have to change. It can still use IOrderRepository
Conclusion
By separating the model from the view, both model and view are much easier to red and understand. Much easier to reuse, change, maintain and unit test. Both can be developed independantly
Procedure are small and have only one task: this makes that we can reuse the procedures. Changes are only in one procedure
By using interfaces, I hide how and where the data is fetched: SQL? CSV-file? Internet?
By using using statements the program is more full proof: after exceptions everything is property closed and disposed
By using SQL parameters I prevented malicious use of SQL injection.
I have C# code that performs basic CRUD Operations. I have a class library defined as AppDal which contains Db Operations (for SQL Server) and I am using namespace in C# code.
How can I use the same c# code to perform db operations for another db like Oracle. I want to set db name in appsettings.json. On that basis, it will decide which db to connect to. I will create another class library for another db like OracleDAL.
using AppDal;
public IActionResult Add(CustomerModel input)
{
ResponseModel response = new ResponseModel();
Dal dal = new Dal();
int Id = dal.Add(input);
if (Id > 0)
{
response.Id = Id;
response.Message = "Record added successfully";
}
else
{
response.Message = "Record not added";
}
return Json(response);
}
namespace AppDal
{
public int Add(CustomerModel input)
{
SqlParameter[] param = new SqlParameter[]
{
new SqlParameter("#Id",input.Id),
new SqlParameter("#CompanyId",input.CompanyId),
new SqlParameter("#Title",input.Title),
new SqlParameter("#Address",input.Address),
};
int result = SqlHelper.ExecuteScalar(SqlHelper.defaultDB, CommandType.Text, CustomerQueries.Add, param).ToInt();
return result;
}
}
It is possible if I create another application but that will increase maintenance time. I want to use same application.
One way to solve this is to create an interface, example IDal that will have all your CRUD signature functions then create a concrete classes that inherit IDal for Sql Server and Oracle.
Then use the interface IDal as declared type for your Dal object. Example,
IDal Dal = DalForSqlServer() or IDal Dal = DalForOracle();
the best way to solve the issue is using ORM like Entity Framework Core. You don't have to change any code but the Entity framework providers. the same code will work for SQL, MySql, Oracle, PostgreSQL, SQL Lite and so on.
few links that can help you : https://github.com/aspnet/EntityFrameworkCore
EF core providers : https://entityframework.net/supported-database-providers
I have created this interface for storing data in a file:
interface IFileStore {
bool Import(string);
string Export();
}
...and a generic class that implements that interface:
class DBTextFile<T> where T : IFileStore, new ()
{
public List<T> db = new List<T>();
public void SaveFile(string filename)
{
foreach(T d in db) File.WriteToFile(d.Export(), filename);
}
public void RestoreFile(string filename)
{
db = new List<T>();
string buffer;
while(buffer = File.Read(filename) != null)
{
T temp = new T();
if(temp.Import(buffer)) db.Add(temp);
}
}
}
This approach has been working for me for a while. However, I'm finding that I'm having to manage too many files. I think it might be more appropriate to use a database where each of my files would become a table in that database.
I would like to use a database that does not require the user to install any software on the user's system. (I want to keep things simple for the user.) Basically, I just want a database that is easy for me, the developer, to use and deploy.
Would MySQL be a good choice? Or would a different database be a better fit for my needs?
You can use different one file databases.
The one I'm using and am happy with is : SQLite.
You could also use access as Monika suggested, or browse google and see what else you can find ...
I basically have created a class which when a user logs into a website it then queries the database and stores some settings in a List (So I have key/pair values).
The reason for this is because I want to always be able to access these settings without going to the database again.
I put these in a class and loop through the fields via a SQL query and add them to the list.
How can I then access these variables from another part of the application? or is there a better way to do this? I'm talking server side and not really client side.
Here is an example of what I had at the moment:
public static void createSystemMetaData()
{
string constring = ConfigurationManager.ConnectionStrings["Test"].ConnectionString;
SqlConnection sql = new SqlConnection(constring);
sql.Open();
SqlCommand systemMetaData = new SqlCommand("SELECT * FROM SD_TABLES", sql);
//Set Modules
using (SqlDataReader systemMetaDataReader = systemMetaData.ExecuteReader())
{
while (systemMetaDataReader.Read())
{
var name = systemMetaDataReader.GetOrdinal("Sequence").ToString();
var value = systemMetaDataReader.GetOrdinal("Property").ToString();
var Modules = new List<KeyValuePair<string, string>>();
Modules.Add(new KeyValuePair<string, string>(name, value));
}
}
}
Thanks
Any static properties of a class will be preserved for the lifetime of the application pool, assuming you're using ASP.NET under IIS.
So a very simple class might look like:
public static class MyConfigClass
{
public static Lazy<Something> MyConfig = new Lazy<Something>(() => GetSomethings());
public static Something GetSomethings()
{
// this will only be called once in your web application
}
}
You can then consume this by simply calling
MyConfigClass.MyConfig.Value
For less users you can go with the SessionState as Bob suggested,however with more users you might need to move to a state server or load it from Data Base each time.
As others have pointed out, the risk of holding these values in global memory is that the values might change. Also, global variables are a bad design decision as you can end up with various parts of your application reading and writing to these values, which makes debugging problems harder than it need be.
A commonly adopted solution is to wrap your database access inside a facade class. This class can then cache the values if you wish to avoid hitting the database for each request. In addition, as changes are routed through the facade too, it knows when the data has changed and can empty its cache (forcing a database re-read) when this occurs. As an added bonus, it becomes possible to mock the facade in order to test code without touching the database (database access is notoriously difficult to unit test).
From the looks of things you are using universal values irrespective of users so an SqlCacheDependency would be useful here:
Make sure you setup a database dependency in web.config for the name Test
public static class CacheData {
public static List<KeyValuePair<string,string>> GetData() {
var cache = System.Web.HttpContext.Current.Cache;
SqlCacheDependency SqlDep = null;
var modules = Cache["Modules"] as List<KeyValuePair<string,string>>;
if (modules == null) {
// Because of possible exceptions thrown when this
// code runs, use Try...Catch...Finally syntax.
try {
// Instantiate SqlDep using the SqlCacheDependency constructor.
SqlDep = new SqlCacheDependency("Test", "SD_TABLES");
}
// Handle the DatabaseNotEnabledForNotificationException with
// a call to the SqlCacheDependencyAdmin.EnableNotifications method.
catch (DatabaseNotEnabledForNotificationException exDBDis) {
SqlCacheDependencyAdmin.EnableNotifications("Test");
}
// Handle the TableNotEnabledForNotificationException with
// a call to the SqlCacheDependencyAdmin.EnableTableForNotifications method.
catch (TableNotEnabledForNotificationException exTabDis) {
SqlCacheDependencyAdmin.EnableTableForNotifications("Test", "SD_TABLES");
}
finally {
// Assign a value to modules here before calling the next line
Cache.Insert("Modules", modules, SqlDep);
}
}
return modules;
}
I've got an MVC3 project and one of the models is built as a separate class library project, for re-use in other applications.
I'm using mini-profiler and would like to find a way to profile the database connections and queries that are made from this class library and return the results to the MVC3 applciation.
Currently, in my MVC3 app, the existing models grab a connection using the following helper class:
public class SqlConnectionHelper
{
public static DbConnection GetConnection()
{
var dbconn = new SqlConnection(ConfigurationManager.ConnectionStrings["db"].ToString());
return new StackExchange.Profiling.Data.ProfiledDbConnection(dbconn, MiniProfiler.Current);
}
}
The external model can't call this function though, because it knows nothing of the MVC3 application, or of mini-profiler.
One way I thought of would be to have an IDbConnection Connection field on the external model and then pass in a ProfiledDbConnection object to this field before I call any of the model's methods. The model would then use whatever's in this field for database connections, and I should get some profiled results in the MVC3 frontend.
However, I'm not sure if this would work, or whether it's the best way of doing this. Is there a better way I'm missing?
ProfiledDbConnection isn't dapper: it is mini-profiler. We don't provide any magic that can take over all connection creation; the only thing I can suggest is to maybe expose an event in your library that can be subscribed externally - so the creation code in the library might look a bit like:
public static event SomeEventType ConnectionCreated;
static DbConnection CreateConnection() {
var conn = ExistingDbCreationCode();
var hadler = ConnectionCreated;
if(handler != null) {
var args = new SomeEventArgsType { Connection = conn };
handler(typeof(YourType), args);
conn = args.Connection;
}
return conn;
}
which could give external code the chance to do whatever they want, for example:
YourType.ConnectionCreated += (s,a) => {
a.Connection = new StackExchange.Profiling.Data.ProfiledDbConnection(
a.Connection, MiniProfiler.Current);
};