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.
Related
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
LINQ just seems to generate horrendously optimised SQL (in general). I can write way more efficient T-SQL myself.
Do huge websites with my thousands of daily visitors use LINQ? Or should LINQ at some point be ditched? And if so, with what? and when?
Do huge websites with my thousands of daily visitors use LINQ?
Yes. Why not? Most SQL is trivial and you can always fall back to a stored procedure where it matters.
And that is the point. Let LINQ handlethe easy 80% and focus on the more complex.
And ther rest you handle by not talking to the database - caching is not that hard to plan for.
What I have done with my apps, when L2S or EF creates inefficient T-SQL is to create a view that does exactly what I want, in an efficient manner and I just have L2S or EF query the view.
In fact, this website (stackoverflow) uses linq2sql extensively, although I believe they are using a micro-orm (sqlfu?) for some of the heavier taks..
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.
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 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'm working on a project that we're using .NET MVC 3 and EF 4. The website is growing and there are a lot of tables. So, the table designer of Entity Framework too much CPU usage t open and add new tables. What are my options? What can I do?
For larger models, I think the designer approach is less desirable. If you can, consider refactoring (one bite at a time?) to a code-first approach; this will allow you to keep using current technology. I have a project with ~650 entities working perfectly fine, but I can't imagine loading a .edmx designer with ~650 entities (without pulling my hair, that is).
All in all, it's not EF that's "heavy" - it's the designer.
Starting with Visual Studio 2012, you can now split your Entity Model into multiple diagrams. This'll reduce the diagram complexity a lot.
See
http://msdn.microsoft.com/en-us/magazine/jj721589.aspx
http://msdn.microsoft.com/en-us/data/jj519700.aspx
If you database operations are large in general you may consider not using EF and use raw ADO.NET instead. EF boils down to ADO.NET at the low level anyway but using ADO.NET right away will improve performance.
Moving to a code first architecture is definitely something to consider for the long term. For the short term, you also might be able to break your model up into multiple design contexts. You can start this by identifying areas of the application that only use a subset of the tables. Then create a separate data context that only includes those tables. You can keep the existing omnibus context around while you're working on this to avoid breaking legacy code. You can add as many data contexts as you like, but I would create each one in a separate folder (and therefore a separate namespace) so you don't have to worry about name collisions.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Can someone please explain to me the Repository Pattern in .NET, step by step giving a very simple example or demo.
I know this is a very common question but so far I haven't found a satisfactory answer.
As a summary, I would describe the wider impact of the repository pattern. It allows all of your code to use objects without having to know how the objects are persisted. All of the knowledge of persistence, including mapping from tables to objects, is safely contained in the repository.
Very often, you will find SQL queries scattered in the codebase and when you come to add a column to a table you have to search code files to try and find usages of a table. The impact of the change is far-reaching.
With the repository pattern, you would only need to change one object and one repository. The impact is very small.
Perhaps it would help to think about why you would use the repository pattern. Here are some reasons:
You have a single place to make changes to your data access
You have a single place responsible for a set of tables (usually)
It is easy to replace a repository with a fake implementation for testing - so you don't need to have a database available to your unit tests
There are other benefits too, for example, if you were using MySQL and wanted to switch to SQL Server - but I have never actually seen this in practice!
This is a nice example: The Repository Pattern Example in C#
Basically, repository hides the details of how exactly the data is being fetched/persisted from/to the database. Under the covers:
for reading, it creates the query satisfying the supplied criteria and returns the result set
for writing, it issues the commands necessary to make the underlying persistence engine (e.g. an SQL database) save the data