Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm a beginner in c# and i'm looking for the best way to connect to and work with sql server in c#. i found there are three ways to work with databases:
ADO.NET
Linq
Entity Framework
but i become confused as to which one is more useful and applied.
please help me?
thanks
I'm looking for best way to connect to and work with sql server in c#
'best way' can be treated differently depending on your project requirements. There is no best way for all cases. Some times you need ease of development, some times you need best performance, some times you need compromise of both (then I pick Dapper). Also it depends on complexity of your application - whether you have rich domain model, or you simply display table data on UI.
1.ADO.NET
Fastest way, but requires lot of manual coding. You should manually setup database connections, open and close them, create commands, provide parameters to commands and execute commands. Mapping of query results also should be done manually.
2.Linq
It's not way to connect to database. Linq is language integrated queries, which have many implementations - Linq to Xml, Linq to DataSet, Linq to Object, Linq to SQL, Linq to Entities etc.
3.Entity Framework
Entity Framework uses Linq to Entities and it is built on ADO.NET (internally Linq queries are are translated to ADO.NET code). It is easy to use, because EF handles connections, generate and execute commands, and map query results to entities for you. But you should pay with performance for that.
There is only ONE way to connect to a database . ADO.NET, more specifig: the Connection object.
Now, LINQ, ENtity Framework - guess what, they do not talk to the database. They use ADO.NET to do that.
They are all about easier programming in the application - talking to the database is done by the same underlying classes. Everything goes through a Connection, a Command and a SqlReader if data is returned.
That said, definitely learn Entity Framework - an ORM is baseline and writing handcrafted SL should be left to those instances it makes sense. Very complex queries that can not be expressed in an ORM form. And learn proper SQL - databases can do a LOT more than most people are aware of.
There is no "best way", because there are many advantages and disadvantages to each one of them, so it depends.
For example, entity framework is heavy, but convenient way to connect to database. It generates objects from your tables and views automatically.
LINQ is less heavy, but some people find it less convenient.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 months ago.
Improve this question
Please consider these assumptions:
I have a high traffic web application with millions records in database tables.
Suppose I know enough about EF and how to properly use it in its optimal way.
I prefer to use EF in my applications due to its compatibility with OOP and ease of use.
I know EF (even with best practice usages) has some performance downsides in compare with Dapper or ADO.NET.
But my question is that based on my assumptions, is this performance issue considerable or I can use EF safely in my high traffic web application?
I have a high-traffic web application with millions records in database tables.
No one (mostly not the database) cares about millions of records unless you forget to put indices on it. Way more interesting is how complex the queries are. Most queries - particularly those that can use an index at least to reduce the numbers parsed - are trivial load on billions of records, but a join over 15 tables hat forces 100gb of data into tempdb is a problem.
I know enough about EF and how to properly use it in its most optimize way.
I doubt that, particularly for EF Core which seems to change every weekend. But ok, you do avoid the most stupid things, like one dbcontext for the whole application.
I know EF even with best practice usages has some performance downsides in compare with Dapper or ADO.
This is so totally not true. The point is more - EF does a lot that neither Dapper nor ADO directly do, and this comes with a price. This is like "A Ferrari is faster than a truck, but there are downsides".
The truck is slow - except if you transport a lot of stuff. I.e. queries come with a lot of overhead - but if you do not care about ever updating the data you query (typical in web applications), then turn off change tracking for this query. Getting objects has an overhead - ok, happens.
But you can filter which properties you materialize. Do it and the amount of data goes down. EF is not exactly super fast - but it is not exactly awful either. Dapper and ADO(.NET) beat it, but they do less.
In fact, EF is built on top of ADO.NET, because unless you plan to write the whole network stack yourself, ADO.NET is the only way to talk to most databases.
The whole problem is: what do you think is high traffic? I have seen EF successfully deployed in applications with tens of thousands of parallel users. I have then made some critical functions 100 times faster because the pro programmers knew everything about EF - but no one taught them how to put the proper indices on tables.
EF is perfectly capable on large applications, but depending on usage you may have to scale to some servers, unless you write very efficient user level code and avoid inefficient things like enumerating all values and then filtering in memory (and yes, I have seen this - particularly with "we do repositories around EF" people that then thought returning an IEnumerable is a good idea).
There is nothing in EF that will inhibit your application's scalability. If there is a performance difference, you can compensate with additional resources. And you can manage the tradeoff between resource cost and development cost on a case-by-case basis, rather than making an up-front Architecture Decision.
And an EF application with selected performance-critical transactions implemented in ADO.NET and/or Stored Procedures is typically not materially slower or more expensive to run than an application written entirely with ADO.NET and Stored Procedures.
As long as you're aware of best practices, and beware of absolute "DO NOT"s, yes it is. There always will be developers who don't know what they're doing and joins a List<> object into a Linq query which will result fetching all records on that table. There always be another who joins or includes all relations when it is not necessary. And another who fetches the entity with all of its fields when the code actually needs one field from that entity.
We're using entity framework core in a big government project, having hundreds of millions data in many tables and having hundreds of requests per second in a work day. As long as you also optimize table indexes and relationships correctly, it's all fine. It's not about the library, it is about whether you use it wisely or not.
Dapper encourages to write plain SQL and thus you can have more control if you are a SQL expert; you can write complex queries the way you like. It is still faster than EF core. There are certain verbosity with EF core using code-first. For instance for composite foreign key you have to override OnModelCreating and specify the rules. Further to specify different table-names other than the model you have to write code for it. If you happen to make changes in the Migration table(which usually happens during testing) then you might have to do the subsequent commits (for model changes) manually in the database after generating the scripts and analyzing the difference visually.
The question is "Do we have to think of ways to optimize Dapper?" Then answer is "No, it is by default optimized".
Another question is "Do we have to think of ways to optimize EF core?" Then answer is "Yes, you have to take lot of things into consideration".
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am currently exploring of using Entity framework for the windows based (forms) application I'm developing that does data mining for a dataset of more than 1 million rows (my datasources are from oracle, sql server, sqlite). What the application will do is I parse these information to the users local client, and I utilize linq to objects in mining useful information. The said application shall only read information to the source database as its output is written in an excel file.
Given the significant ease of using the Entity Framework in terms of reducing the development time (this is the first time I will be using an ORM, and coding the necessary dataaccess objects takes about 80% of my time based on the previous projects I've done before), I would like to ask if it's worth it to use EntityFramework to the application I'm working in? How much would be the performance drop (as compared to using DataReaders) when reading tables for over 1 Million rows?
Also, given that I'm new to this technology, I would much appreciate it if you could refer me to useful tutorials and best practices.
Using pure ADO.NET will give you practically best performance you could get. But bear in mind that after you fetch data from data source, you would still need to map results to your object model (something that is done by EF automatically) so that you can perform actual data mining.
Mapping could be tough or easy process to do depending on how complex your data model is. For example, Entity Framework is good at mapping hierarchical data structures, which is useful when fetching related entities (or even their related entities) along with the actual entity.
You should also consider how often does your data model changes (and how big those changes are), so you calculate maintainability cost too. Having tons of SQL that you have to change every time you add new column is another point of getting problems. In this case, maintaining EF model with POCO's would be easier and more convenient.
Note that there are other O/RMs that can give you kind of best of two worlds (performance of DataReader and easy mapping to POCOs of Entity Framework). Among these are: NPoco (former PetaPoco), Dapper (the one used at StackOverflow), NHibernate (using HQL can be quite fast), OrmLite (has basic LINQ-like queries support) and many others.
Take a look at Dapper's performance benchmarks results that might give you some picture of what performance can be achieved with popular O/RMs.
Performance of either technology of fetching data is really dependent on what data model you have in the database.
That's why it's important not only to analyze existing benchmarks, but also perform your own based on your particular use cases on your data model. As a starting point, you can grab Dapper's performance tests code and tweak it according to your needs (data model, typical queries, etc), so that you get more comprehensive and realistic performance results using different frameworks.
EF is never as fast as using raw ADO.NET with an OracleCommand. After all, EF is another layer on top of ADO.NET; it's main goal is to provide programmers with convenience features of mapping raw columns into fields and rows into objects.
If you need the absolute top-notch performance, then you need to use raw ADO.NET. The downside of this is the fact that you need to start fiddling around with untyped rows and columns.
There ain't no free lunch - either you have top performance but an unpleasant programming API, or you get convenience and productivity - at a performance price.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently learning LINQ especially SQL requests with the entity framework.
I used to write native SQL-queries before, and I've implemented it with one class in my projects called "SQL_Connection" or something.
So I had all my SQL-procedures stored in one class.
Now as I'm willed to learn the entity framework the right and cleanest way from beginning, I'm asking myself where do I put all those linq-procedures I create during a project.
Do expierienced people put them in the class-file of the related class, or are they using a big sql-class where all those procedures are stored in?
I'm asking myself where do I put all those linq-procedures I create during a project.
Where you create them.
If you are not totally ignorant on .NET you will have a TON of LINQ queries and only SOME will be EF related - the syntax is the same. You will use LINQ in your code to sum and aggregate in memory arrays, and do a lot of things.
The beauty of LINQ is that all changes to the underlying provider are isolated and / or checked by the compiler, so there is no need to have all in one place "in case I rename a table".
I keep the LINQ where I need it. This allows me to isolate layers without having a mother of all queries class. Especiall as some of the LINQ queries are multi step queries involving one or more data access then grouping and correlating in memory.
Seriously, the "one class to rule them all" (sql) is an artefact of the fact that SQL is a string, so in case of a database change you need to find all SQL that touches that changed element and that please without going through tons of code. This is absolutely not needed with LINQ.
That's up to your pleasure. Answering the question: do create BLL classes for your related set of objects. By this, a minor change won't make you itchy. Assume you added a new column to a table, having that table's (and other related ones') operations located easily is good, right? Avoid too big files. Try to stay modular and etc.
If you need a reading, check out this Wiki link about MVC architecture.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am learning C# and I want to access a database. I have been searching pages on .net database connectivity for the last two - three days. I also came to know that it has several ways for the connectivity and this is exactly where my mind started to ask a number of questions. Please tell me if I am wrong in my understanding.
Check out this Diagram 1.
Now what I am getting here are five ways of connectivity:
Linq to Objects
Linq to Datasets
Linq to SQL
Linq to Entities
Linq to XML
Here is another Diagram 2 of ADO.net Architecture -
I have read the definitions, but am not able to differentiate the functionality and purposes. Can anyone give me a short explanation of both diagrams for my understanding?
Suppose I am a programmer who write code in C#; which way should I
prefer to write desktop based has database connectivity that
has future?
To Software Developer is it needed to go through all the
preceding ways of data access from database?
For the answer to number 1, use Entity Framework and a database. The database could be relational (like SQL Server), or document-based (like MongoDb). If you just grab the free Visual Studio 2013 express and start by creating a new project from a template, you'll probably end up with some version of SQL Server to start out with.
You have a lot of options for Linq to Whatever because sometimes you just have to get data out of repository and if you can use Linq as a facade to it, then getting your data out is that much easier because it feels a lot like getting data out of a database. There's even Linq to Twitter. For a brand new project though, you'll most likely use a database.
For the answer to number 2, you would only do that on an existing application that you are maintaining. It is fine technology, but if you're creating a new project, use Entity Framework.
Under the covers of all the data libraries, every time you access the database three things happen:
- a connection is made to the database
- a command is created (to select, update, insert or delete data)
- the command is executed in the database
In the case of LINQ or EF, the SQL for the command is generated automatically from your objects, but ultimately, the same three actions happen.
If you want to understand the basics, start with the ADO.NET objects. If you want to get something running more quickly take a look at EF, or nHibernate.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am working on a collaborative-filtering recommender system. I built such a system before in a parallel-threaded environment, querying RDF with SPARQL. This worked well, because of the parallel nature of SPARQL and RDF graphs. However, I am now working in a standard desktop PC, and am wondering if using SPARQL is still the way to go in a largely serial environment. I've looked at dotNetRDF, as I'm using C#, and am wondering if it is any more efficient than simple SQL, especially now that dotNetRDF seems to be moving away from a SQL back-end.
So as far as performance on a few threads go, SQL or dotNetRDF? Tables or graphs?
The two things are not really comparable, dotNetRDF is a programming API that provides support for a variety of storage backends in addition to a pure in-memory solution which we mainly recommend for testing and development (Disclaimer I'm the lead developer)
The different backends have a wide variety of performance characteristics so if your problem is expressible in RDF then likely there is an appropriate backend for you.
SQL is a query language, really you should be comparing SQL to SPARQL and ultimately which you chose comes down to what your data model looks like. If it's regular then you likely want to use a RDBMS and SQL, if it's irregular and/or graph like then you likely want to use a triple store and SPARQL. The two have different pros and cons as your own answer implies.
This seems to answer it well enough. Triple Stores vs Relational Databases
Essentially, RDF is much more flexible, but expensive. Since I'm just doing collaborative filtering with data that fits pretty well into a table, I don't think I need the extra expense, as much as I like graphs.