Inserting data in database in Asp.Net . Which way is better? [on hold]











up vote
0
down vote

favorite












I am working on a Asp.Net website to insert data in the database. After reading different articles on internet where it is suggested that we should use a parametrized query as it prevents from SQL Injection attacks.



So I am wondering which way is better:



Create a Stored Procedure with parameters in the database and then call it in the button click event to insert the data in the database e.g.



CREATE PROCEDURE AddInfraction
@Description varchar(255), @Penalty money, @Points int
AS
BEGIN
INSERT INTO Infractions (Description, Penalty, Points)
VALUES (@Description, @Penalty, @Points)
END

using (SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString))
{
using (SqlCommand command = new SqlCommand("AddInfraction"))
{
command.CommandType = CommandType.StoredProcedure;
command.Parameters.AddWithValue("Description", Description.Text);
command.Parameters.AddWithValue("Penalty", Convert.ToInt16(Penalty.Text));
command.Parameters.AddWithValue("Points", Convert.ToInt16(Points.Text));
connection.Open();
queryResult = command.ExecuteNonQuery();
if (queryResult == 0)
{
return;
}
}
connection.Close();
}


Or maybe first by adding the ADO.NET Entity Data Model in the database and then in the button click event creating the object of the data model recently added, and then call the particular stored procedure and inserting the data in the database.



using (ETrafficChallanSystemEntities eTrafficChallanSystemEntities = new ETrafficChallanSystemEntities())
{
eTrafficChallanSystemEntities.AddInfraction(Description.Text,
Convert.ToInt16(Penalty.Text), Convert.ToInt16(Points.Text));
}


Which one would be the best way to insert data in the database.










share|improve this question















put on hold as primarily opinion-based by Daniel A. White, S.Akbari, Manfred Radlwimmer, AdrianHHH, EdChum Nov 10 at 16:54


Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.















  • The best way is your preference. Personally, I would not use a stored procedure if I was using Entity Framework.
    – Crowcoder
    Nov 10 at 14:00










  • Is it safe enough from SQL Injection Attacks
    – SameerAli
    Nov 10 at 14:02






  • 2




    yep. its safe since you are using parameters.
    – Daniel A. White
    Nov 10 at 14:03










  • Parametized queries are both the safest and potentially faster (because a lot of checks/translation can be done on the Programm side). No idea where ADO.Net comapres to it. But if you need explicit casting, that is usually a bad sign for type safety and thus Injection Proofing.
    – Christopher
    Nov 10 at 14:22















up vote
0
down vote

favorite












I am working on a Asp.Net website to insert data in the database. After reading different articles on internet where it is suggested that we should use a parametrized query as it prevents from SQL Injection attacks.



So I am wondering which way is better:



Create a Stored Procedure with parameters in the database and then call it in the button click event to insert the data in the database e.g.



CREATE PROCEDURE AddInfraction
@Description varchar(255), @Penalty money, @Points int
AS
BEGIN
INSERT INTO Infractions (Description, Penalty, Points)
VALUES (@Description, @Penalty, @Points)
END

using (SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString))
{
using (SqlCommand command = new SqlCommand("AddInfraction"))
{
command.CommandType = CommandType.StoredProcedure;
command.Parameters.AddWithValue("Description", Description.Text);
command.Parameters.AddWithValue("Penalty", Convert.ToInt16(Penalty.Text));
command.Parameters.AddWithValue("Points", Convert.ToInt16(Points.Text));
connection.Open();
queryResult = command.ExecuteNonQuery();
if (queryResult == 0)
{
return;
}
}
connection.Close();
}


Or maybe first by adding the ADO.NET Entity Data Model in the database and then in the button click event creating the object of the data model recently added, and then call the particular stored procedure and inserting the data in the database.



using (ETrafficChallanSystemEntities eTrafficChallanSystemEntities = new ETrafficChallanSystemEntities())
{
eTrafficChallanSystemEntities.AddInfraction(Description.Text,
Convert.ToInt16(Penalty.Text), Convert.ToInt16(Points.Text));
}


Which one would be the best way to insert data in the database.










share|improve this question















put on hold as primarily opinion-based by Daniel A. White, S.Akbari, Manfred Radlwimmer, AdrianHHH, EdChum Nov 10 at 16:54


Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.















  • The best way is your preference. Personally, I would not use a stored procedure if I was using Entity Framework.
    – Crowcoder
    Nov 10 at 14:00










  • Is it safe enough from SQL Injection Attacks
    – SameerAli
    Nov 10 at 14:02






  • 2




    yep. its safe since you are using parameters.
    – Daniel A. White
    Nov 10 at 14:03










  • Parametized queries are both the safest and potentially faster (because a lot of checks/translation can be done on the Programm side). No idea where ADO.Net comapres to it. But if you need explicit casting, that is usually a bad sign for type safety and thus Injection Proofing.
    – Christopher
    Nov 10 at 14:22













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I am working on a Asp.Net website to insert data in the database. After reading different articles on internet where it is suggested that we should use a parametrized query as it prevents from SQL Injection attacks.



So I am wondering which way is better:



Create a Stored Procedure with parameters in the database and then call it in the button click event to insert the data in the database e.g.



CREATE PROCEDURE AddInfraction
@Description varchar(255), @Penalty money, @Points int
AS
BEGIN
INSERT INTO Infractions (Description, Penalty, Points)
VALUES (@Description, @Penalty, @Points)
END

using (SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString))
{
using (SqlCommand command = new SqlCommand("AddInfraction"))
{
command.CommandType = CommandType.StoredProcedure;
command.Parameters.AddWithValue("Description", Description.Text);
command.Parameters.AddWithValue("Penalty", Convert.ToInt16(Penalty.Text));
command.Parameters.AddWithValue("Points", Convert.ToInt16(Points.Text));
connection.Open();
queryResult = command.ExecuteNonQuery();
if (queryResult == 0)
{
return;
}
}
connection.Close();
}


Or maybe first by adding the ADO.NET Entity Data Model in the database and then in the button click event creating the object of the data model recently added, and then call the particular stored procedure and inserting the data in the database.



using (ETrafficChallanSystemEntities eTrafficChallanSystemEntities = new ETrafficChallanSystemEntities())
{
eTrafficChallanSystemEntities.AddInfraction(Description.Text,
Convert.ToInt16(Penalty.Text), Convert.ToInt16(Points.Text));
}


Which one would be the best way to insert data in the database.










share|improve this question















I am working on a Asp.Net website to insert data in the database. After reading different articles on internet where it is suggested that we should use a parametrized query as it prevents from SQL Injection attacks.



So I am wondering which way is better:



Create a Stored Procedure with parameters in the database and then call it in the button click event to insert the data in the database e.g.



CREATE PROCEDURE AddInfraction
@Description varchar(255), @Penalty money, @Points int
AS
BEGIN
INSERT INTO Infractions (Description, Penalty, Points)
VALUES (@Description, @Penalty, @Points)
END

using (SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["DefaultConnection"].ConnectionString))
{
using (SqlCommand command = new SqlCommand("AddInfraction"))
{
command.CommandType = CommandType.StoredProcedure;
command.Parameters.AddWithValue("Description", Description.Text);
command.Parameters.AddWithValue("Penalty", Convert.ToInt16(Penalty.Text));
command.Parameters.AddWithValue("Points", Convert.ToInt16(Points.Text));
connection.Open();
queryResult = command.ExecuteNonQuery();
if (queryResult == 0)
{
return;
}
}
connection.Close();
}


Or maybe first by adding the ADO.NET Entity Data Model in the database and then in the button click event creating the object of the data model recently added, and then call the particular stored procedure and inserting the data in the database.



using (ETrafficChallanSystemEntities eTrafficChallanSystemEntities = new ETrafficChallanSystemEntities())
{
eTrafficChallanSystemEntities.AddInfraction(Description.Text,
Convert.ToInt16(Penalty.Text), Convert.ToInt16(Points.Text));
}


Which one would be the best way to insert data in the database.







c# sql asp.net stored-procedures ado.net-entity-data-model






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 10 at 14:04

























asked Nov 10 at 13:52









SameerAli

113




113




put on hold as primarily opinion-based by Daniel A. White, S.Akbari, Manfred Radlwimmer, AdrianHHH, EdChum Nov 10 at 16:54


Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.






put on hold as primarily opinion-based by Daniel A. White, S.Akbari, Manfred Radlwimmer, AdrianHHH, EdChum Nov 10 at 16:54


Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.














  • The best way is your preference. Personally, I would not use a stored procedure if I was using Entity Framework.
    – Crowcoder
    Nov 10 at 14:00










  • Is it safe enough from SQL Injection Attacks
    – SameerAli
    Nov 10 at 14:02






  • 2




    yep. its safe since you are using parameters.
    – Daniel A. White
    Nov 10 at 14:03










  • Parametized queries are both the safest and potentially faster (because a lot of checks/translation can be done on the Programm side). No idea where ADO.Net comapres to it. But if you need explicit casting, that is usually a bad sign for type safety and thus Injection Proofing.
    – Christopher
    Nov 10 at 14:22


















  • The best way is your preference. Personally, I would not use a stored procedure if I was using Entity Framework.
    – Crowcoder
    Nov 10 at 14:00










  • Is it safe enough from SQL Injection Attacks
    – SameerAli
    Nov 10 at 14:02






  • 2




    yep. its safe since you are using parameters.
    – Daniel A. White
    Nov 10 at 14:03










  • Parametized queries are both the safest and potentially faster (because a lot of checks/translation can be done on the Programm side). No idea where ADO.Net comapres to it. But if you need explicit casting, that is usually a bad sign for type safety and thus Injection Proofing.
    – Christopher
    Nov 10 at 14:22
















The best way is your preference. Personally, I would not use a stored procedure if I was using Entity Framework.
– Crowcoder
Nov 10 at 14:00




The best way is your preference. Personally, I would not use a stored procedure if I was using Entity Framework.
– Crowcoder
Nov 10 at 14:00












Is it safe enough from SQL Injection Attacks
– SameerAli
Nov 10 at 14:02




Is it safe enough from SQL Injection Attacks
– SameerAli
Nov 10 at 14:02




2




2




yep. its safe since you are using parameters.
– Daniel A. White
Nov 10 at 14:03




yep. its safe since you are using parameters.
– Daniel A. White
Nov 10 at 14:03












Parametized queries are both the safest and potentially faster (because a lot of checks/translation can be done on the Programm side). No idea where ADO.Net comapres to it. But if you need explicit casting, that is usually a bad sign for type safety and thus Injection Proofing.
– Christopher
Nov 10 at 14:22




Parametized queries are both the safest and potentially faster (because a lot of checks/translation can be done on the Programm side). No idea where ADO.Net comapres to it. But if you need explicit casting, that is usually a bad sign for type safety and thus Injection Proofing.
– Christopher
Nov 10 at 14:22












4 Answers
4






active

oldest

votes

















up vote
0
down vote



accepted










Both the methods are good to insert data in the database. Using a parameterized query is always a good option. I would suggest using the second method as you have already added the ADO.NET Entity Model in your project.






share|improve this answer




























    up vote
    1
    down vote













    as mentioned, this should be your preference. however with the recent trend of microservices patterns, it's likely better to tie less of your application logic to a database product. really depends on what the application is for and how often the backend will shift






    share|improve this answer








    New contributor




    Ming L is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.

























      up vote
      0
      down vote













      There is not an absolute answer to this question. Any program(Application) has own requirement, but I think about some points on using each method.



      A) Using Stored Procedures Pros:




      • For the first time run is slow but for next times is so fast.

      • Data Processing logic is unique and integrate, So changing that is
        so easy, understandable, fast, liable and clean.

      • Migrating from one IDE/Language/Maybe Framework to another is easy because most business logics are in DB layer, So many of cod changing converting stored procedure call in the new language.


      B) Using the Entity Data Model Pros:




      • Didn't spend the time to write safe and powerful Stored procedures.


      • Data Processing logic can be changed slowly and through the coding
        progress.


      • Having meaningful and clear sight of DB entities(Tables/Views and
        relations) In coding time.


      • can be changed DataBase architecture in some scenarios such as
        Code-First programming.



      After all, I think Maybe better to keep Entity Model way for the most changeable/front-end related/little process section and Using Stored Procedures for persistent/Deep Backend related/Huge and multi-process sections.






      share|improve this answer




























        up vote
        0
        down vote













        I don't recommend using Stored Procedure for simple read/write queries, for the following reasons:




        • Some logic is implemented in the database and is outside your source control

        • Harder to maintain

        • More verbosity for the project


        For your case Entity Framework (Microsoft Database Framework) can cover almost 90% of cases.



        Of if you want more control over your Sql Queries, you can use a Query Builder like Sql Kata (I am the author of this library)






        share|improve this answer




























          4 Answers
          4






          active

          oldest

          votes








          4 Answers
          4






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          0
          down vote



          accepted










          Both the methods are good to insert data in the database. Using a parameterized query is always a good option. I would suggest using the second method as you have already added the ADO.NET Entity Model in your project.






          share|improve this answer

























            up vote
            0
            down vote



            accepted










            Both the methods are good to insert data in the database. Using a parameterized query is always a good option. I would suggest using the second method as you have already added the ADO.NET Entity Model in your project.






            share|improve this answer























              up vote
              0
              down vote



              accepted







              up vote
              0
              down vote



              accepted






              Both the methods are good to insert data in the database. Using a parameterized query is always a good option. I would suggest using the second method as you have already added the ADO.NET Entity Model in your project.






              share|improve this answer












              Both the methods are good to insert data in the database. Using a parameterized query is always a good option. I would suggest using the second method as you have already added the ADO.NET Entity Model in your project.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Nov 10 at 14:14









              Junaid Sultan

              1201111




              1201111
























                  up vote
                  1
                  down vote













                  as mentioned, this should be your preference. however with the recent trend of microservices patterns, it's likely better to tie less of your application logic to a database product. really depends on what the application is for and how often the backend will shift






                  share|improve this answer








                  New contributor




                  Ming L is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






















                    up vote
                    1
                    down vote













                    as mentioned, this should be your preference. however with the recent trend of microservices patterns, it's likely better to tie less of your application logic to a database product. really depends on what the application is for and how often the backend will shift






                    share|improve this answer








                    New contributor




                    Ming L is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.




















                      up vote
                      1
                      down vote










                      up vote
                      1
                      down vote









                      as mentioned, this should be your preference. however with the recent trend of microservices patterns, it's likely better to tie less of your application logic to a database product. really depends on what the application is for and how often the backend will shift






                      share|improve this answer








                      New contributor




                      Ming L is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                      Check out our Code of Conduct.









                      as mentioned, this should be your preference. however with the recent trend of microservices patterns, it's likely better to tie less of your application logic to a database product. really depends on what the application is for and how often the backend will shift







                      share|improve this answer








                      New contributor




                      Ming L is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                      Check out our Code of Conduct.









                      share|improve this answer



                      share|improve this answer






                      New contributor




                      Ming L is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                      Check out our Code of Conduct.









                      answered Nov 10 at 14:46









                      Ming L

                      111




                      111




                      New contributor




                      Ming L is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                      Check out our Code of Conduct.





                      New contributor





                      Ming L is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                      Check out our Code of Conduct.






                      Ming L is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                      Check out our Code of Conduct.






















                          up vote
                          0
                          down vote













                          There is not an absolute answer to this question. Any program(Application) has own requirement, but I think about some points on using each method.



                          A) Using Stored Procedures Pros:




                          • For the first time run is slow but for next times is so fast.

                          • Data Processing logic is unique and integrate, So changing that is
                            so easy, understandable, fast, liable and clean.

                          • Migrating from one IDE/Language/Maybe Framework to another is easy because most business logics are in DB layer, So many of cod changing converting stored procedure call in the new language.


                          B) Using the Entity Data Model Pros:




                          • Didn't spend the time to write safe and powerful Stored procedures.


                          • Data Processing logic can be changed slowly and through the coding
                            progress.


                          • Having meaningful and clear sight of DB entities(Tables/Views and
                            relations) In coding time.


                          • can be changed DataBase architecture in some scenarios such as
                            Code-First programming.



                          After all, I think Maybe better to keep Entity Model way for the most changeable/front-end related/little process section and Using Stored Procedures for persistent/Deep Backend related/Huge and multi-process sections.






                          share|improve this answer

























                            up vote
                            0
                            down vote













                            There is not an absolute answer to this question. Any program(Application) has own requirement, but I think about some points on using each method.



                            A) Using Stored Procedures Pros:




                            • For the first time run is slow but for next times is so fast.

                            • Data Processing logic is unique and integrate, So changing that is
                              so easy, understandable, fast, liable and clean.

                            • Migrating from one IDE/Language/Maybe Framework to another is easy because most business logics are in DB layer, So many of cod changing converting stored procedure call in the new language.


                            B) Using the Entity Data Model Pros:




                            • Didn't spend the time to write safe and powerful Stored procedures.


                            • Data Processing logic can be changed slowly and through the coding
                              progress.


                            • Having meaningful and clear sight of DB entities(Tables/Views and
                              relations) In coding time.


                            • can be changed DataBase architecture in some scenarios such as
                              Code-First programming.



                            After all, I think Maybe better to keep Entity Model way for the most changeable/front-end related/little process section and Using Stored Procedures for persistent/Deep Backend related/Huge and multi-process sections.






                            share|improve this answer























                              up vote
                              0
                              down vote










                              up vote
                              0
                              down vote









                              There is not an absolute answer to this question. Any program(Application) has own requirement, but I think about some points on using each method.



                              A) Using Stored Procedures Pros:




                              • For the first time run is slow but for next times is so fast.

                              • Data Processing logic is unique and integrate, So changing that is
                                so easy, understandable, fast, liable and clean.

                              • Migrating from one IDE/Language/Maybe Framework to another is easy because most business logics are in DB layer, So many of cod changing converting stored procedure call in the new language.


                              B) Using the Entity Data Model Pros:




                              • Didn't spend the time to write safe and powerful Stored procedures.


                              • Data Processing logic can be changed slowly and through the coding
                                progress.


                              • Having meaningful and clear sight of DB entities(Tables/Views and
                                relations) In coding time.


                              • can be changed DataBase architecture in some scenarios such as
                                Code-First programming.



                              After all, I think Maybe better to keep Entity Model way for the most changeable/front-end related/little process section and Using Stored Procedures for persistent/Deep Backend related/Huge and multi-process sections.






                              share|improve this answer












                              There is not an absolute answer to this question. Any program(Application) has own requirement, but I think about some points on using each method.



                              A) Using Stored Procedures Pros:




                              • For the first time run is slow but for next times is so fast.

                              • Data Processing logic is unique and integrate, So changing that is
                                so easy, understandable, fast, liable and clean.

                              • Migrating from one IDE/Language/Maybe Framework to another is easy because most business logics are in DB layer, So many of cod changing converting stored procedure call in the new language.


                              B) Using the Entity Data Model Pros:




                              • Didn't spend the time to write safe and powerful Stored procedures.


                              • Data Processing logic can be changed slowly and through the coding
                                progress.


                              • Having meaningful and clear sight of DB entities(Tables/Views and
                                relations) In coding time.


                              • can be changed DataBase architecture in some scenarios such as
                                Code-First programming.



                              After all, I think Maybe better to keep Entity Model way for the most changeable/front-end related/little process section and Using Stored Procedures for persistent/Deep Backend related/Huge and multi-process sections.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Nov 10 at 15:39









                              QMaster

                              2,0352144




                              2,0352144






















                                  up vote
                                  0
                                  down vote













                                  I don't recommend using Stored Procedure for simple read/write queries, for the following reasons:




                                  • Some logic is implemented in the database and is outside your source control

                                  • Harder to maintain

                                  • More verbosity for the project


                                  For your case Entity Framework (Microsoft Database Framework) can cover almost 90% of cases.



                                  Of if you want more control over your Sql Queries, you can use a Query Builder like Sql Kata (I am the author of this library)






                                  share|improve this answer

























                                    up vote
                                    0
                                    down vote













                                    I don't recommend using Stored Procedure for simple read/write queries, for the following reasons:




                                    • Some logic is implemented in the database and is outside your source control

                                    • Harder to maintain

                                    • More verbosity for the project


                                    For your case Entity Framework (Microsoft Database Framework) can cover almost 90% of cases.



                                    Of if you want more control over your Sql Queries, you can use a Query Builder like Sql Kata (I am the author of this library)






                                    share|improve this answer























                                      up vote
                                      0
                                      down vote










                                      up vote
                                      0
                                      down vote









                                      I don't recommend using Stored Procedure for simple read/write queries, for the following reasons:




                                      • Some logic is implemented in the database and is outside your source control

                                      • Harder to maintain

                                      • More verbosity for the project


                                      For your case Entity Framework (Microsoft Database Framework) can cover almost 90% of cases.



                                      Of if you want more control over your Sql Queries, you can use a Query Builder like Sql Kata (I am the author of this library)






                                      share|improve this answer












                                      I don't recommend using Stored Procedure for simple read/write queries, for the following reasons:




                                      • Some logic is implemented in the database and is outside your source control

                                      • Harder to maintain

                                      • More verbosity for the project


                                      For your case Entity Framework (Microsoft Database Framework) can cover almost 90% of cases.



                                      Of if you want more control over your Sql Queries, you can use a Query Builder like Sql Kata (I am the author of this library)







                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered Nov 10 at 15:48









                                      amd

                                      13.4k33349




                                      13.4k33349















                                          Popular posts from this blog

                                          Full-time equivalent

                                          Bicuculline

                                          さくらももこ