I am working on window application developed using SCSF and we are using sybase database. As practise we create typedataset in the .net project and then populate them using framework method and for all the sql statement we write stored procedure in the database.
So we have type dataset in memory so I am using linq to select records from datatable. Can I step one step further and use something related to Entity Framework?
Can it reduce my work? I don't have hands-on experience with Entity Framework but can you suggest something in this scenario?
Thanks,
Denish
Entity framework uses similar concepts as the type datasets except for:
The ability to have a class structure that is not exactly the same as the table structure (e.g. class hierarchy, splitting tables into multiple classes, joining tables into one class).
The ability to use LINQ to perform queries in the database instead of in memory.
Entity framework also lets you map results of stored procedures to classes and bring results into memory if you need to run a query that is faster in memory or not translatable to SQL.
For most SQL queries the LINQ to Entity will be effective enough, so you will probably end up writing less stored procedures.
You will have to learn how to use EF and LINQ effectively and use can use 3rd party tools such as Entity Framework Profiler to help you.
Related
I know the benefit of the LINQ and I know use of it in .Net Application. I fill same thing there are providing as a Entity Framework.
So What's Major Difference between LINQ and Entity Framework?
LINQ could be applied to any data source: in-memory objects, XML, SQL, ...
Entity Framework could use LINQ to perform queries against a relational database.
LINQ to SQL is the predecessor of Entity Framework and is obsolete now.
Comparing EF and LINQ is incorrect. Both are different things and they often work together to give better developer experience (and productivity benefit).
LINQ is querying syntax/model that can be applied to any data source. EF provides one such data source.
They are somewhat similar, and can be used in a very similar way, code-wise, but they have some important differences. Note that "LINQ" is not the same thing as "LINQ to SQL"; the EF also uses LINQ. Some notable differences are:
LINQ to SQL is largely SQL Server only, not so much by design as by implementation. The EF is designed to support, and does support, multiple DBs, if you have a compatible ADO.NET provider.
Out of the box, LINQ to SQL has a very poor story for DB metadata changes. You have to regenerate parts of your model from scratch, and you lose customizations.
The EF supports model features like many-to-many relationships and inheritance. LINQ to SQL does not directly support these.
In .NET 3.5, LINQ to SQL had much better support for SQL-Server-specific functionality than the EF. This is mostly not true in .NET 4; they're fairly similar in that respect.
The EF lets you choose Model First, DB First, or Code First modeling. LINQ to SQL, out of the box, really only supports DB First.
SOURCE : Here
I totally agree with VinayC. You cannot really compare.
With Entity Framework, you will be able to have a whole representation of your database in your program. It will help you create classes corresponding to the database elements, connected together like they are in the database. You can after interact with elements of theses classes directly, and like this impact the database. You will have some representation of these classes diagram in visual studio. It's basically often simpler than working directly with the database elements, even if setting it up requires some effort.
The use of Linq is to perform queries on the data sources.
In short: can I use a literal SQL subquery somehow in the entity model without using database views?
Context: I have a bunch of ADO.NET queries that result in C# objects. These objects correspond directly to the query shape; i.e. I can do ObjectContext.Translate to extract them from the SqlDataReader. There are lots of these queries, many quite complex, and some of which use features the entity framework doesn't support (while loops, CTE's, hierarchyids, etc.) - converting these (legacy) queries to LINQ isn't feasible.
However, I'd really like to be able wrap these results and add some custom filtering on the C# side of things: things like sorting, filtering, paging etc. I could convert each and every query into a view (or stored procedure) and map these, but that's a hassle and a maintenance nightmare - but in principle EF can be used with "opaque" SQL queries by that route.
Can I somehow use subqueries written in SQL with the entity model? An ObjectContext.Translate that returns an IQueryable rather than an IEnumerable would be ideal, but not necessary: the vast majority of queries are compile-time constants, so some form of pre-processing is possible.
Edit: I'm looking for something returning an IQueryable so I can add filters/sorting client side but have them executed on the DB (as usual). I'm using Entity Framework code-first.
You can set the DefiningQuery property of an EntitySet to some literal SQL. These are more or less equivalent to a SQL view. Does that solve your issue?
http://msdn.microsoft.com/en-us/library/cc982038.aspx
If your SQL query is giving a result with the same structure as of the entity class, you can use the DbContext.SqlQuery
var customer=context.Database.
SqlQuery<Customer>("SELECT ID,NAME from CUSTOMER WHERE TYPE IN
(SELECT TYPEID FROM IMPORTANT_TYPE)");
Assuming context is your DBContext class object
I got confused on what are the differences between Linq-to-SQL and Entity Framework when following the database first approach as I can not find any clear differences.
In my case when I was using Linq-to-SQL I used to create the tables then I use Linq-to-SQL to create the classes that represents the tables, and now when I switch to Entity Framework I am still following the same steps (creating the database tables then create the associated classes using EF).
And I am interacting with these classes on the same way, for example I used to query the User class using the same syntax and approach but one time when the User class was created using Linq-to-SQL and the other time when it was created using EF, so where is the difference ?
public IQueryable<User> findstudents(string term)
{
return from student in entities1.Users
where student.UserID.Contains(term)
select student;
}
Second question if I use EF to map the tables into classes, is it still possible to use Linq-to-SQL in the same application to query the EF classes?
LINQ is a base technology - that's the syntax that gives you the SQLish query options in C# - that's totally independent of whether you use Linq-to-SQL or EF. So if you want to query your data classes using the LINQ syntax - you can do that with both frameworks - but once you use Linq-to-SQL and once you use Linq-to-Entities. You cannot use Linq-to-SQL against an Entity Framework EDMX model.
Linq-to-SQL is great
if you need very simple 1:1 mapping - one table equals one class in your domain model
if you never need anything else but SQL Server (Linq-to-SQL doesn't support anything else)
if you want to be up and running really quickly
Entity Framework on the other hand
supports multiple backends (SQL Server, Oracle, Firebird - other will likely follow)
supports a full conceptual data modelling strategy - you define the physical model in the database, the conceptual model in your app, and the mapping between the two
gives you the ability to handle things like mapping a single business entity to several tables
support table-per-hierarchy and table-per-class inheritance scenarios
support refreshing/updating your model (EDMX file) from the database when things change (in Linq-to-SQL, you basically have to drop + recreate those entities involved - thus loosing all your customizations you might have made)
In brief: Linq-to-SQL is a great, simple and lean'n'mean ORM for SQL Server - use it, if it does all you need. Entity Framework is quite a different beast, much more capable, but also more complex, much bigger - perfect for your next enterprise-critical app, but probably overkill for your personal blog app :-)
If you want to create something that's "future-proof" and will use the OR technology that Microsoft is pushing into the future, then you should go with Entity Framework. Especially in v4, it's also a lot easier to use, a lot more slimmed down and more useful than ever before.
I want to retrieve rows from an oracle table and convert them into objects.
I am currently using a refcursor result and a datareader in c# to manually convert the rows to objects but this seems messy. Is their a better way of converting rows from a relational table to objects?
EDIT: The project I'm on is not using any ORM tools so unfortunately it is down to little old me to do the mapping!
You can use UDTs and utilize the new ODP functionality to get the data.
this is a walkthrough on getting started:
http://www.oracle.com/technology/obe/hol08/dotnet/udt/udt_otn.htm
while this is a bit more detailed:
http://download.oracle.com/docs/html/E10927_01/featUDTs.htm
but the real meat & potatoes are already installed on your computer after you install ODP in the Samples directory:
%ORA_HOME%\product\11.1.0\client_1\odp.net\samples\2.x\UDT
Utilizing UDTs has helped out our origination and the time response is great.
You could use an ORM like NHibernate, Fluent NHibernate, Linq To Sql, or Entity Framework. ORMs (Object Relational Mappers) exist to turn datatables into objects. You specify which table points to which class, along with which columns point to which members, and the ORM will cast rows into objects. The also take care of your normal CRUD operations, so as soon as you map the tables, you can start interacting with them.
Edit: If you are using .Net 3.5 or later, you get Linq To Sql and Entity Framework (they are included in .Net). If you can't use an ORM, you are stuck doing the casting yourself (essentially, you are the ORM in that case)
A bit of a clarification: I was browsing Julia Lerman's Oreilly title on Entity framework and I got mighty confused.
I have Charlie Calvert's essential LINQ, but from my 10 minute session with Lerman's book, it transpires that LINQ is LINQ to SQL which seems underpowered with its DataContext object etc...
Whereas Entity Framework is the future, but it has something called Entity SQL which to my eye looked exactly like Transact-SQL. Now my eye could be a bit rusty, but the question is:
Since Entity Framework is the main horse that Microsoft is backing, is there any point in learning LINQ to SQL with its
var numberGroups =
from n in numbers
group n by n % 5 into g
select new { Remainder = g.Key, Numbers = g };
And am I confused in thinking that Entity SQL and LINQ are two different technologies, does entity SQL in fact use LINQ?
post the many replies I got:
Ok Folks, I'm new to this, so I'm editing my answer this time ;-)
Many thanks for your full, expedited and very helpful answers.
Regards
MereMortal
LINQ != LINQ-to-SQL
LINQ is the concept, including some language support. There are many implementations - LINQ-to-SQL is one, as is ADO.NET Data Services, Entity Framework's LINQ-to-Entities, LINQ-to-Objects, LINQ-to-SQL, LINQ-to-Amazon, DbLinq, etc.
You still use LINQ with Entity Framework; indeed, LINQ-to-Entities is the preferred choice, giving compile time static checking. Entity SQL is simply another mechanism (in addition to LINQ-to-Entities) for querying the EDM (Entity Data Model).
There are 3 main reasons that ESQL is useful:
it was the only option in early previews when LINQ-to-Entities was still under construction
it can be used in some scenarios where there is no object model, for example reporting services
there is a small number of cases where ESQL is more expressive
For everything else, LINQ should be your tool for working with Entity Framework.
LINQ is a generic term for the language features that permit queries to be written in C# or VB.NET over a data store of some sort. There is LINQ to SQL, LINQ to Entities, LINQ to Objects, etc.
LINQ to SQL closely models the physical database structure. It produces one type for every table in the database. If your database changes, then your LINQ to SQL code will need to change.
LINQ to Entities more closely models the conceptual database design. It allows you to map to the physical database, but for instance, allows you to create one Person entity that includes data from both the Person and Contacts tables. This allows your callers to think in terms of what the data mean instead of how the data are implemented.
Also, Microsoft has said that future development in LINQ to SQL will be limited when compared to the development in LINQ to Entities. Given the increased flexibility and the fact that LINQ to SQL won't get many more enhancements, I'd go with LINQ to Entities and Entity Framework.
As others said, you probably mean Linq to SQL vs Entity Framework.
Both work for SQL Server, but only Entity Framework will work for other databases. Also, LINQ to SQL has, more or less, been depreciated. So go with Entity Framework.
Linq is a programming construct that allows you query your objects
there is a Linq to Sql that I think you are talking about.
you can always use linq to query EF objects...
Whoa whoa. Slow down there.
Short Answer: Entity Framework
Longer Answer:
LINQ to SQL and Entity Framework are data access technologies.
Linq is, according to MS,
LINQ is a set of extensions to the .NET
Framework that encompass
language-integrated query, set, and
transform operations. It extends C#
and Visual Basic with native language
syntax for queries and provides class
libraries to take advantage of these
capabilities.
from : http://msdn.microsoft.com/en-us/netframework/aa904594.aspx
Both LINQ to SQL and Entity Framework have Linq providers, which allow for that awesome syntax when querying against them.
Entity Framework has LINQ to Entities, so you can execute very the same query against EF as well. And my answer will be invest more to EF, because upcomming EFv4 seems promissing.
From what I understand, EF is not quite ready for prime time yet, and it does not support many of the LINQ constructs that work so easily today in LINQ2SQL.
If you can commit to SQL Server for your application, I say today, learn LINQ2SQL. You'll have more capabilities in querying when using LINQ.
I'm betting when EF is ready, it'll be a much easier transition for you since the query language should be transferrable.
Good luck.
I go in microsoft TehcDays in Montreal on december 2 and 3, and they said, that they will no longer support LINQ to sql in few year, so your better start to learn LinQ to entity (Entity framework).