Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best Practices for accessing data in .NET (non MVC)

Tags:

c#

.net

asp.net

I am using .NET 3.5, and looking at old code done by someone else and trying to add security and update it.

What are the best practices for accessing data in a web forms project?

Currently I am changing the code to use SQL parameterization, like so:

using (SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings[ConfigurationManager.AppSettings["defaultConnection"]].ConnectionString))
{
    using (SqlCommand myCommand = new SqlCommand(sql.ToString(), conn))
    {
        myCommand.Parameters.AddWithValue("search1", mySearchVar);
        ...

I know SQL parametization is important, but I see other people using stored procedures? Is they other ways, best practices to follow?

like image 211
cdub Avatar asked Nov 21 '12 20:11

cdub


People also ask

How does .NET access data?

It takes two types of data controls to retrieve and display data in ASP.NET: A data source control - It manages the connection to the data, selection of data, and other jobs such as paging and caching of data etc. A data view control - It binds and displays the data and allows data manipulation.

Which block of .NET framework is also called Data Access Layer?

The recommended approach, however, is to separate the data access logic from the presentation layer. This separate layer is referred to as the Data Access Layer, DAL for short, and is typically implemented as a separate Class Library project.

Should .NET Core API be async?

ASP.NET Core apps should be designed to process many requests simultaneously. Asynchronous APIs allow a small pool of threads to handle thousands of concurrent requests by not waiting on blocking calls. Rather than waiting on a long-running synchronous task to complete, the thread can work on another request.


2 Answers

If it's not just small refactoring and you have time to rewrite your data access layer, use some ORM:

NHibernate

Entity Framework

Dapper.NET (Stackoverflow ORM)

BLToolkit

like image 142
Dmitry Khryukin Avatar answered Oct 14 '22 23:10

Dmitry Khryukin


There is nothing wrong with using ADO.NET. It's what drives all the ORM solutions in .NET.

Yet it seems .NET developers are running in droves to jump on the ORM bandwagon. ORMs are just one of many tools in the data access toolbox.

In the early 2000's ORMs took the Java world by storm. Store procedures were shunned. It was ORM or nothing. A half decade later Java developers realized that the best solution uses both an ORM and stored procedures, each has strengths.

Use the best tool for the job. ORMs can automate much of the CRUD from the application. Stored procedures are good for adding abstraction, adding a layer of security and optimizing area's that need to be highly performant.

Choose the best tool for the job.

like image 44
Chuck Conway Avatar answered Oct 14 '22 23:10

Chuck Conway