I hear a lot of linq-to-sql bashing and how people will unknowingly abuse it. But how is linq-to-sql being abused?
Update
If someone can give me clear examples of how it's abused that would be very helpful. References to blogs/tutorials would be very helpful as well.
Thanks.
One of the easiest mistakes to make is to create a query which results in a loop of calls to the database instead of a single call returning all the data. For this reason it's worth checking what sql commands are hitting the database either in the debugger or with a trace.
There are many ways that LINQ->SQL can be abused just like poorly written inline SQL/ADO.NET/SPs or what have you.
Alot of what you might have heard is how LINQ itself might be abused.
I think one example of it being misused would be as a total replacement for SQL in views or stored procedures on the server, and therefore potentially more lax security on the database server.
Well... if you can write complicated queries with linq-to-sql it's probably because you know SQL syntax and are pretty good at writting the query in SQL in the first place. So why would you use the .NET syntax to write a syntax tree that then another layer of software would translate (perhaps not very efficiently) into SQL for you?
Just write the damn thing in SQL in the first place :-)
Related
I have an indexed view that I need to specify the noexpand hint for in order for it to perform reasonably. Unfortunately as seen with regard to modifying the Linq to SQL generated T-SQL query from the NOLOCK hint it appears that there is no easy way to take advantage of these hints directly or is there?
My thought is that it would make sense to allow customization of this stuff through the use of attributes or declaratively through the dbml. Also since Linq to SQL seems to only work targeting SQL Server it only makes sense that we are also able to leverage these advanced features (if they exists). Regardless of the implementation though I'm interested in any creative ways of solving this problem.
I've found a workaround which appears to work but requires making a second View for each SQL View that one would want to use the NOEXPAND hint with. In the second view just select all of the fields from the original view and tack on the NOEXPAND hint. Any Linq to SQL query that needs to use the NOEXPAND hint can now just target that view that wraps the original.
More details can be found in this MSDN post.
One down side among others to consider when creating dependent views is that you will have to make sure to apply the creation scripts in the proper dependency order
Does anybody have any better alternatives? I would rather not have to create extra SQL Views just to support usage of this necessary optimizer hint.
I totally agree, but I do not believe there is such a method. In EF4 you can use the ExecuteStoreCommand that will let you execute SQL directly. That may be your only option if performance is unacceptable.
==EDIT==
You can also do this in LINQ to SQL through the ExecuteQuery method.
http://msdn.microsoft.com/en-us/library/bb399403.aspx
Thus far used sql server stored procedures for all my web applications... Now thought of moving to an ORM... I would like to ask SO users about LINQ to SQL
Is Linq to sql worth a try as a beginner to an ORM?
or should i look for some others... Any suggestion...
EDIT:
I have a sql server 2005 database with all tables....
How to use this db with Linq to sql?
Coming from using ADO.NET table adapters, LINQ was a revelation. A breath of fresh air. The veil was lifted. A new day dawned. And so on and such forth.
Start with Scott Gu's series here and check all his other blogs on the subject.
I envy you your impending joy.
Skip it. Second grade little ORM missing all the interesting features (and don't get me even started with EntityFramework - crap in v1, barely usable in v2).
I suggest getting ahold of NHibernate.
Even though I, unfortunately, don't do much Windows/.NET development anymore, I still think that C#/.NET is the best programming environment around and that Linq is a great ORM. If you're on the .NET/C# platform, use it. There's good documentation, a large community of users to help you, and very solid implementations.
While Microsoft SQL Server doesn't get a lot of buzz, it is a very worthy database to be the platform underlying linq.
If you're just starting, then I recommend you ignore LINQ to SQL. Microsoft will be placing all of their development efforts behind Entity Framework, which is more powerful and general than LINQ to SQL.
Coming from a similar situation I found linq-to-sql worked really well. We previously used a repository pattern and managed to follow it pretty closely with linq to sql in about half the time. Linq-to-Sql will also allow you to write and use regular store procedures.
For a beginner I found the linq-to-sql sections of the Nerd Dinner tutorial a good starting point.
Personally, I think that L2S is a great choice for a ORM beginner because it's really easy to use, but still gives you plenty of power. IMO, if you are doing new SQL Server work, L2S is the best and easiest ORM available. It's not perfect, but neither is anything else out there.
Also, PLINQO adds a lot of the missing features to L2S that bring it more in line with EF, while maintaining the simplicity and speed of L2S.
Is there any software for Windows that allows you to setup your tables and then tell the software what you want to SELECT given the conditions and it will tell you the SQL query that you need? Thanks.
Probably you'll find software that will do this for you in a GUI, but eventually you will be required to write the queries yourself, unless you're developing something really trivial.
A GUI tool for SELECT statements is a too-high level of abstraction for most scenarios, and you would have to face the "Law of Leaky Abstractions" eventually.
Visualization tools are quite handy for defining the database schema, and there are some very good tools for that. However queries remain quite tricky to visualize, in my opinion. I think you'll be able to mentally visualize queries, given enough practice. Nevertheless, I'm quite sure you will be able to get started doing SQL queries within a few days, even non-trivial ones.
In addition, you can use Stackoverflow if you require assistance with complicated queries. I'm quite sure that the community here will suggest better SQL than any GUI tool!
These sound like they will do what you want:
SQL Maestro
dbForge Query Builder for MySQL
Having said that, I do agree with the other answers here - learning to manually write SQL will give you a lot more control. I highly recommend the (free) MySQL Workbench for that.
The people at sqlmanager.net build some tools to deal with databases, but I agree with Daniel: if you have very complex queries to work with, it's probably more work telling the tool what to do that creating the queries manually - especially as you'll have to verify what the tool did, so if you can do that, you could have done it by hand in the first place :)
As said before by daniel vassallo, you should learn how to create those sql queries "by hand". where i work we use a program that does exactly this (it's used by accountants only) and it creates horrible sql select statements and we have constantly whining accountants that think that the problem is allways on the server side even when we show them that those queries get them the wrong data... it's a never ending circle :(
Use HeidiSQL to manage your database, and keep an eye on what's going on in the SQL log. You'll soon pick it up.
Our team is now beginning to look at jumping from 2.0 to 3.5 and have been reviewing all the new stuff....
So, with the whole Linq to SQL not being heavily improved in the future should we ignore it completely?
It seems that it may fit of our needs very well BUT I imagine so could entity framework even if it may add more complexity.
So avoid Linq To SQL like to plague and go with entity framework instead or jump on in, Linq To SQL will be just fine in 4.0 and future releases even without improvements?
Everything I've read seems to suggest that Linq2SQL will still be around for a while. I would, if I were you, just pick the one that best suits the problem you're trying to solve. I might be a little biased toward using the Entity Framework because it's more abstract and might be a good capability for you and your team to have, and because Visual Studio 2008 has a designer for it.
I just don't think it's that big a deal for a few years. Just pick the one you like the best for now.
Update: lest there be any confusion - using the EF doesn't mean giving up Linq. Linq can already be used with the EF.
Very similiar to my question # Switching to LINQ
Might offer further insight/opinions.
Personally, I am going to start focusing on EF since everything I see coming from MS is that LINQ is just the beginning and a big part of the foundation of EF.
I would pick LINQ only because it is simpler, and when you finish your application, and are looking at optimizing, and refactoring, then you can try Entities, and see if you have any performance improvements, or if it makes the code better.
I tend to start with the simpler, faster-to-develop, method, to get the functionality finished, then I refactor, then optimize.
I'd have picked EF in any case. I never liked the idea that LINQ to SQL mapped directly to the database structure. I greatly preferred the idea of EF, where I can decide what entities I want to present to users, and then map them to the database tables as appropriate.
LINQ to SQL and Entity framework are not comets passing by. They are real coding revolutions !
We can now query databases in 1 hour where it took us 1 day before !
Do not hesitate to jump. If .Net 4.0 does not suport LINQ to SQL or Entity framework, just stick to 3.5 !
:o)
All the best, Sylvain.
If LINQ to SQL fits your needs, then go with it. Its really a very powerful RAD tool.
EF will give you more flexibility, but also perhaps unnecessary complexity.
Its a shame LINQ to SQL isn't moving forward anymore, but I'd stick to it until EF really matures and allows equal RAD development, unless of course, you need EF features now.
I would say that it depends. Everyone else so far has put things very well.
Use LINQ-to-SQL if you don't mind the fact that your eventual object model is going to very closely mirror your database. There's not a lot you can do with or to a LINQ-to-SQL model if you find that you want to model things differently.
Use EF if you want to potentially use the same framework to point to multiple types of data, or if you'd like to abstract your database model more than is possible in LINQ-to-SQL.
I don't have any data on, say, performance differences between the two models, unfortunately.
I wouldn't say the fact that MS isn't doing a lot of active development on LINQ-to-SQL should necessarily scare you away. Its a very good, very, very basic object mapping solution.
I am hearing a lot of rumours that Linq2Sql is not going to be supported any more in the next version of .net. I like Linq2Sql a lot and find it very easy / lightweight to work with. I can understand some of the problems people have had with it (ppl used to nhibernate...) but used correctly I think most problems can be solved. I currently use it in all my projects now and I would hate to see that it isn't going to be supported any more.
So list the disadvantes you see with Linq2Sql
If there were another version of Linq to SQL, here's my feature wishlist:
Things I actually wanted whilst building my last Linq-to-SQL project (and had to work around manually in most cases)
Many-many associations
Better visual designer (including a "refresh table" feature)
Control over cascade delete/update/SET NULL that doesn't involve hacking the XML
Specific mappings for culture/string comparisons into SQL COLLATE statements (e.g. specifying whether passwords should be case sensitive or not, rather than relying on the default collation of the underlying database.)
Things I might want but haven't actually needed yet:
Support for ordered collections (persisting lists to the DB so they are automatically retrieved in the same order they were persisted)
LINQ to SQL can certainly be fixed. But so long as the ADO.NET team is in charge of it, I seriously doubt it will be.
If it gets open sourced I think it will be a force to be reckoned with. But as it stands, it is a dying technology.
One of the biggest disadvantages I see in L2S is that it is a really hassle to use it in disconnected scenarios; send off a serialized version of an entity to another and try to "merge"/update it when you get it back and you will see it's shortcomings. If the .Attach() functionality had worked for such scenarioes, L2S would have been quite nice.
--larsw
First and foremost, people are losing interest in it since it will not be developed any further, and Entity Framework will go forward instead.
LinqToSQl works and is pleasant to use, but EF will overtake it sooner or later.
The ORM purists would prefer if it was easier to set up LINQ to Sql to use an object model that is external to the LINQ to SQL data layer. This can be done in Linq to SQl, but it's a manual process that's far from the default configuration.