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 6 years ago.
Improve this question
After reading forums and articles, I found that using the Entity Framework
you can quickly create a database, and ADO can be used to conventional SQL queries and get accurate results. Also there are many questions all over the internet: what is better, ADO or EF? And in responses saying that need to combine these two technologies, each in its own good. But here's the question of how combine these two technologies and use them in the same project?
For example, i have several tables that mapped to entites, like employee and tasks. With EF i can create new employees and add them to database. But what if i want to create a report, that can be easely created with complex SQL query from many tables. The result of this SQL query can't match existing entities, so what to do? Create new entity-model to match this report and create this LINQ query to build it, or use ADO and SQL query?
EF actually use ADO deep inside itself.
If you want to execute plain SQL in EF you can use theese methods:
SqlQuery() //for selects
ExecuteSqlCommand() //for Delete, Insert, Update
Check msdn.
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 5 years ago.
Improve this question
The goal of this app would be a support for any database that is supported by EF. Well actually I need it only to be able to create tables, modify records in the tables, and modify columns of the tables. As for now (I am a newbie) I can't imagine how to modify an existing table by adding or removing it's columns without pressing "Update model from database" in the VS environment -
that is, programmatically. If it is impossible, making it with SQL queries would be OK for me...
Entity Framework is designed to generate DML (Data Modelling Language) statements i.e. SELECT, UPDATE, INSERT and DELETE statements against a database. It is not designed to generate DDL (Data Definition Language) statements, i.e. CREATE, ALTER, DROP etc, which are used to modify the database schema. Therefore Entity Framework is not the correct tool for the requirement you describe.
I am quite sure you can. While I have never tried it with Entity Framework (you should use ADO.NET nowadays), it should be possible. The tasks you consider (creating tables, modifying tables, or modifying records) is eventually done by sending the corresponding SQL CREATE TABLE or ALTER TABLE or UPDATE commands to the RDBMS.
As an aside, just bear in mind that relational databases usually do not allow for easy adding/removing of database columns. The so called no-SQL databases do, however.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I am working on a project that started with code-first POCO objects representing database structure. For development purposes we use drop and create when database is changed.
There is a new requirement for providing support for OData queryable endpoints. So I created new ADO.NET Entity Data model (generated from existing database).
I would like to use EDM only for retrieving data from database views.
But as far as I understand there is no way how to specify them "in code" so they would be persisted in the EDM. And if I create a view in the database, regenerate EDM and then change the code-first structure, the DB is regenerated and view is gone.
This is a problem only for development phase but a big one.
Only solution to this problem I can think of is to keep a SQL definition of all views and execute them when Entity Framework is creating the database.
Is there a better way?
Code first approach does not support creating Views. So you have to look for other options. I would suggest creating migrations (auto upgrade works in most cases) and avoid using drop/create method. This would preserve Views and keep all the benefits of code first.
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 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 a beginner in Entity framework , I want to use LINQ in EF. so please guide me from where i should start learn, what is the basic resources for this .
Try these two links
http://msdn.microsoft.com/en-us/data/ff628210.aspx
http://msdn.microsoft.com/en-us/library/bb386964.aspx
The best way to learn is to use them in the real projects
There are basically three ways you can query data in EF:
LINQ To Entities - Uses standard LINQ operators; more intuitive
Entity SQL - Syntactically similar to TSQL; targets Conceptual Schema directly
Query Builder Methods - Uses Extension Methods defined on IEnumerable and IQueryable
LINQ To Entities is the most preferred way followed by Query Builder Methods.
You can start by understanding most common operators used with LINQ To Entities. Eg., from, join, into, let, group by, order by, select, etc.