I want to use LINQ in ASP.NET to make the performance fast with the quick access to SQL Server 2008.
I want to know how to use the Linq queue in C#. So I can perform all Linq query in my project.
This page is your friend, study it :)
101 examples of linq used in simple, yet extensive ways, should be no problem expanding on this
http://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b
Good answer for a badly structured Question I suppose
Related
Just like to ask, I want to create a blog with ASP.NET as a practice to get better. I came from PHP btw.
Anyway I'm stuck because I don't know what's the way most .NET programmers use to connect to the database. I'm planning on using LINQ.
Any tutorial/books and also websites that would point me to the right dorection would really help. Thanks a lot!
The way most .NET programmers use to connect to databases is ADO.NET, included with the Microsoft .NET Framework. Here some useful code examples.
LINQ ist not designed as a replacement for ADO.NET, LINQ provides a uniform programming model for any kind of data. With it, you can query and manipulate data by using a model that is independent of data sources.
var query =
from c in Customers
where c.Country == "Usa"
select c.CompanyName;
foreach (string name in query)
Console.WriteLine(name);
.NET developers use ADO.NET to connect to relational databases. This is the low level API. Entity Framework provides an ORM on the top of ADO.NET that could map relational tables to objects.
If you are new i will advise you to start with linq, but before that you should learn a little bit about ADO.Net, and whats better then msdn tutorials:
ADO.Net:
http://msdn.microsoft.com/en-us/library/h43ks021%28v=vs.71%29.aspx
http://msdn.microsoft.com/en-us/library/cc161165.aspx
Linq:
http://msdn.microsoft.com/en-us/library/bb386964.aspx
http://www.codeproject.com/Articles/246861/LINQ-to-Entities-Basic-Concepts-and-Features
Looking for a bit of advice on this.
I have a fairly robust .net web app where up till now ive only had to deal with records (in a sql server database) one at a time.
I now have a requirement to do a batch update, of probably around 100 - 200 records at a time.
I prefer using LINQ for querying, I know its not the best but just through personal choice I suppose.
What would be the best way to approach this?
thanks
DD
If you want to update a set of records using a single SQL statement, you won't be able to do that with LINQ. You can certainly do a group of updates together, but it will be one statement per update using standard LINQ. If you've already got a LINQ connection open, I'd suggest constructing a SQL command using that, enlisting it in the same transaction as any queries you've started with LINQ if necessary.
I'm building a new web application project and am confused by the numerous methods of performing data access. I'm backending on SQL and a bit confused whether to use LINQ to SQL or trtaditional ADO.net ?
what are the advantages and disadvantages of using LINQ/SQL over ADO.net?
If it is ADO.net,then what is the best way to retrieve data means either calling the stored procedures or directly calling the t-sql code?
My question is what is cleanes and most effiecient and professional way of creating DAL for webapplication in asp.net?
Thanks
What are the advantages and
disadvantages of using LINQ/SQL over
ADO.net?
Linq2sql generates a series of
classes that are 1-to-1 mappings of
your (selected) database tables - this means you don't have to write tedious and error prone data access code
using ado.net yourself.
Linq2sql may not provide enough value for you if you intend on using a custom object-to-relational mapping (non 1-to-1) - of course you could still use linq2sql, but it would mean having an extra layer in between.
Linq2sql allows you to easily query the database using powerful linq expressions. Writing linq queries provides you with intellisense that you wouldn't get if you embedded your queries as strings inside ado.net commands, or wrote stored procs in management studio.
Using linq, you don't need to know t-sql while you will if you use ado.net (although it can definitely an advantage if your linq queries start doing strange things!). An example of this the complexity of writing t-sql queries that provide paging resultsets simply becomes .Skip(page * size).Take(size).
Linq2sql automatically creates t-sql that uses parameterised queries which is much more secure against sql injection attacks than handwritten ado.net code which builds up a query using a string.
Linq2sql doesn't work very well with stored procedures - you are probably better off not bothering with linq2sql if using sprocs.
Linq2sql could require your database tables to be less-tightly locked down than would be possible writing ado.net code using stored procedures.
If it is ADO.net,then what is the best
way to retrieve data means either
calling the stored procedures or
directly calling the t-sql code?
If you'd ruled out linq2sql, and ado.net happened to the better choice for data retrieval, I would be surprised if you were directly calling t-sql code very often or even at all. I would almost certainly expect you to be using stored procedures for reasons that you have queries that are too complex using linq, and/or security requirements.
My question is what is cleanest and most effiecient and professional way of creating DAL for webapplication in asp.net?
In my opinion, the cleanest DAL would probably use linq2sql as it is the lightest and most targeted ORM for SQL Server (assuming your still interested in SQL Server for this specific question of course).
The most efficient could be the handwritten one using ado.net, but this is probably a waste of time as more often than not, you will find a tool such as linq2sql writing better queries than 90% of developers.
In my opinion, the most professional DAL could be linq2sql, but it is more likely to be the Entity Framework of NHibernate (as other answers have suggested) due to more flexibility.
My last choice DAL in terms of cleanliness and professionalism would definitely be a handwritten ado.net one.
The best way to go is O/RM. Small apps Linq2Sql, larger apps Entity Framework 4 or NHibernate (Fluent NHibernate).
Calling SPs from your code means that your app logic is placed somewhere else than in the app code. It's a way to go but at present less and less popular because of TDD.
The best way is to create DAL into a separated logic layer, own assembly.
I would without doubt go for Linq2Sql.
Download Linqpad and play around with the included samples to get started.
You should check out some ORM frameworks, like NHibernate: http://nhibernate.info
If you want efficient data access in terms of performance than there is nothing faster than pure ADO.NET. You chan check it out here: http://ormbattle.net/.
I am wondering if it is possible to use Linq functionality to connect to a database like my-sql
If it is possible are you able to use the designer to created the DataAccessLayer like with MS-SQL or do you have to hand code its content.
Thanks in advance.
KJ
Linq to Sql only works with MS-SQL. Entity Framework can access several different database back ends and it fully supports linq. NHibernate can access more databases but it's linq support is not yet complete.
You could use IQToolkit.
Yeah check this out
http://code.google.com/p/dblinq2007/
There has been a few posts just recently on this too, just search on stackoverflow for more details.
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 22 days ago.
Improve this question
I want to learn ORM and I wonder which is beneficial for start up; Linq to SQL or Nhibernate. considering time,adaptation... etc
One important question to ask yourself is if you can accept a dependency on SQL Server. Will the database backend change to Oracle, for example? LINQ to SQL is strongly coupled to SQL Server, whereas NHibernate isn't. I'm not saying that this is necessarily a bad limitation, but it's important to consider.
NHibernate has really come a long way in the past few years. I really like Fluent NHibernate, for example, but that's not to say that LINQ to SQL is limiting. I love the integration with Visual Studio and it has proved itself more than capable of handling consistent load (Stack Overflow uses LINQ to SQL, for example).
Contrary to popular belief, LINQ to SQL is not dead.
Edit: Another important question to ask yourself is if you want to change the domain model. LINQ to SQL maps objects directly to tables. NHibernate, on the other hand, allows for a layer of indirection. This is also true of Entity Framework, by the way.
I'd go with NHibernate, because there's a nice open source community out there that supports it, answers questions on it, and so on. As your product gets bigger and more complicated, you'll appreciate the power and flexibility of NH. Finally, Linq-to-sql isn't in MS's long term plans, since they want you to use the Entity Framework, so you might end up with a dead-end technology there.
I would put in my vote for Linq-to-SQL - why?
it has a visual designer which allows you to more easily and quickly get results and see something
NHibernate is very powerful - but that also makes it harder to learn; you have to really really love angle bracket soup (i.e. lots of XML mapping files) to get up to speed with NHibernate
If you don't have experience with ORMs Linq to SQL is slightly easier to learn than NHibernate. It also has better integration with Visual Studio.
I love Linq to SQL, it's very easy to use. Implement the repository pattern and use LINQ to SQL as your first implementation behind your repository interface. You'll find it's so easy to get a repository up quickly using the tool. You can always implement a second repository using NHibernate without breaking your app then compare your experience with the two tools.
NHibernate is "more powerful"... I guess that means you can use it against any database, and that's about it. There's a lot more to learn and if you do go that route, make sure you make full use of Fluent NHibernate to avoid all the mapping rubbish. It's much cleaner that having a bunch of XML mappings to maintain.
I find NHibernate frustrating becuase I like querying the database with LINQ and projecting (mapping) to a model . I know there is a LINQ to NHibernate floating around, but I can't say I know anyone who uses it.
Generally, I would say to use NHibernate if you are happy to get everything by ID and traverse the object model from there. As soon as you want to execute more complex queries you had best be prepared for some frustration.
Linq to SQL is supposed to be replaced by the Entity Framework; I think NHibernate would be a good choice since there are lots of references and it seems be widely used as well.
In addition to Darin answer, Consider this post i read earlier.
Linq to SQL is easier and faster to implement and integrate quickly, but Nhibernate can give you more flexibility if you need more control. Recently, i had to decide if i was to use Linq to SQL on my new app project - i just didn't like the lack of flexibility.
NHibernate vs LINQ to SQL
http://www.acceptedeclectic.com/2007/12/linq-to-sql-vs-nhibernate-part-1-what.html
Let me know if it helps.