Recently I am using LINQ. But when facing an interview I am unable to explain:
What is LINQ?
Moreover, is DataSet deprecated due to the introduction of LINQ?
From an interview point of view, how should I answer those questions?
LINQ is a set of extensions to the .NET framework that enables language-integrated queries. This basically means that we can use the same type of syntax to query any set of data - whether it be a SQL database, Active Directory, or XML file - we can use the same syntax to execute queries.
The mechanism that LINQ uses to communicate with the different datasources is through providers - you can write your own provider if you wish, but the default providers are LINQ-to-Objects, LINQ-to-SQL and LINQ-to-XML. So again - LINQ allows you to use the same syntax for retrieving data from a SQL database, XML file or in-memory objects.
LINQ does not replace DataSets - in fact, you can use LINQ in conjunction with datasets. The only reason why there is a debate of DataSets vs LINQ is due to LINQ-to-SQL being an ORM. This means that we now have a choice in terms of built-in technologies for communicating with the database - previously datasets would be the default built-in option, now you can also opt for LINQ-to-SQL.
Nice introduction to LINQ Just pick few most important sequences from there for your interview question. As for the second question DataSet's are not deprecated, LINQ is just adding a different way you can work with your data.
In addition to what #RaYell said you should have asked your interviewer if they were talking about LINQ or LINQ to SQL when asking if the DataSet was deprecated.
Entity Framework replaces LINQ to SQL, using an OOD approach, shielding it from the database with a mapping layer. This layer uses xml and csql to enable it to pass the data to a variety of databases, without the overhead of sql. The objects dont expose any tables, and neither would you expect it, as the objective is to abstract to enable mapping. This is clearly at odds with the dataset approach. I guess if you considered "Entity Framework to Dataset", or "Entity Framework to XML" in the same vein as LINQ, and to enable loading of these objects shielded by mapping, then you can see the value of each of these technologies. Such transformation atm seem to be via LINQ to XML, or LINQ to DATASET, and then pushing into Entity Framework. I would add that the DataSet allows for accessing tables, rows, columns dynamically and I am not sure the Entity FrameWork has such capability, it must know the data framework, hence they are complementary technologies.
Related
I'm creating a lightweight database to rent movies.
I really like LINQ, so want to stick to that. My forms need validation so that is a requirement (ComponentModel.DataAnnotations).
Is there a model tool/template/thingy that combines them all, giving me the opportunity to create classes, generate them to the database (like the ADO.NET Entity Data Model), giving me LINQ (like LINQ to SQL Classes) and form validation (letting me implement ComponentModel.DataAnnotations)
Simply use Entity Framework - it supports all you need. Check this ScottGu's article for more info.
I have an asp.net web forms application that uses linq 2 sql. A lot of the controls are databound to linq datasource controls.
I want to clean up this application so I can easily use html5's offline functionality.
I thought I should probably move my linq 2 sql statements from code behind to classes and then call to the class. Not sure?
What I would like to do, is have a clean separation and since MS is no longer promoting linq 2 sql, I would like to move to linq 2 entities.
Eventually, a while from now, I would like to convert this app into mvc, but one step at a time.
Would it be better to just make separate data classes for each form or just create database first linq to entity classes?
Thanks,
Sheri
I would recommend reviewing the Repository Pattern suggestions here. I've been using the Repository Pattern with LINQ-to-SQL and ASP.NET MVC since 2009, and it has been very good for me for managing my data interactions, maintaining separation of concerns, and, especially, testing.
I'm attempting to setup Entity Framework using Code First on an existing database. The database isnt in great shape (poor naming convention and some constraints are needed). The application I'm building is an MVC app. I have a "Model", "Repository", and "Web" (mvc) tiers.
To setup EF and map my model objects (POCO objects), is it required that I match my objects to database tables? Can I, instead, use my own stored procedures for CRUD operations? Would it help if I use WCF data services?
I'm planning on using fluent configurations to map my objects, but having some issues due to the database schema. I'm know considering redesigning the database just to get EF to map correctly. Any suggestions would be greatly appreciated!!
Looks awfully similar to this question:
Does Entity Framework Code First support stored procedures?
The answers there may be helpful to you, as well as the discussion surrounding how Code First and Stored Procedures don't make a whole lot of sense.
Wow, Julie Lerman answered!
Yes, it's possible, but not particularly easy. In particular, you must call context.Database.SqlQuery<T>() where T is the entity type you want to return, and your SQL must match up to that entity type. Otherwise, you will have to massage a result set into a type.
In general, you will have to do most of this manually, although you could probably figure out a T4 template to generate it for you, or maybe use some other tool like CodeSmith.
When is it appropriate to create a helper class for a sql server database using the asp.net framework? Basically I'm trying to create a minature wiki (with multiple pages) and storing all of the data/strings for a specific page into a table on it's own.
Always and Never.
Always, because you want good separation of your data tier from your business logic and presentation tiers (or model and view, or whatever framework you use). Make sure you're thinking of it in these terms, too.
Never, because this is already done for you, on several levels. There are numerous ORMs out there, including Linq-to-sql, NHibernate, Entity Framework, and more. More than that, what is ADO.Net but a set of classes to encapsulate your server?
Well it could be appropriate to return a single instance of a DbConnection object - that way you only specify how to connect to the DB in one spot.
You may find it useful to have a base class for your ADO layer which provides these generic methods to deal with the ADO (part of the .NET framework for connecting to SQL server).
You could have a helper method to populate an object from a DataReader using reflection too.
Also for putting parameters together to send to a SQL command or Stored procedure.
Hope you find this helpful. :)
It's heavily dependant on your project.
For code clarity, and your own sanity, you might find it easier to make a wrapper class for all of your Database manipulation. This way you can have the rest of your code work with native objects, rather than the contents of a DataReader.
Just my advice, but hopefully helpful.
I am develop a medium system in ASP.net with MS SQL Server Database and I wonder what is the best way to create a model layer with LINQ or create own classes that dealing with database?
The best way is subjective, but I think the easiest is to use LINQ to SQL.
Using the LINQ designer is a great way to build your model in a UI avoiding the need to write any code. You can setup object hierarchy using the inheritance option and also have associated classes which you can access via the datacontext in code. All of the SQL is then handled for you and means you don't have to write anything, simply call SubmitChanges() on the datacontext. All of the generated code can be viewed, but there is a lot to take in.
I would suggest to try writing your own classes manually with the LINQ attributes etc so you get an idea of what it is doing behind the scenes. Then you will realise how the inheritance and association is implemented and actually makes the designer easier to understand too.