July 21, 2009 at 11:22 pm
Dear All,
I am working in asp.net and along with Sql server 2008, i have requirement to implement LINQ or Entity Data Model (EDM) in my application. so i need to know what is the defference between LINQ and EDM. And, why not SQL Server?
July 22, 2009 at 10:08 am
LINQ is just a short name for Language INtegrated Query which provides query functionality in .NET for many things including XML, Object Collections, SQL Server with LINQ to SQL, and Entity Framework. Last year Microsoft made it public that Entity Framework is the path they will be continuing development on, if you choose to use an ORM solution that has to be LINQ to SQL or Entity Framework then EF is the way to go:
That being said, you should probably do some research before you jump into this. An appropriately built data model and code base will outperform the autogenerated code systems all day every day.
http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html
They are more complex to write and take a little bit more time, but if done correctly the application is separated from the database design keeping things flexible for change, and performance improvements by restructuring database designs as requirements change.
In either case, you should utilize stored procedures to access the database. This goes for LINQ to SQL, Entity Framework, ADO.NET data adapters, and SqlClient SqlDataReader queries to minimize cache bloating from adhoc requests, improve security, and separate your database layer from your application layer.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
July 23, 2009 at 5:46 pm
It's not valid to say "always stored procedures". It totally depends on the application.
In any case, unless the stored procedures are plain old CRUD ones then ORMs (including Linq2Sql and EF) don't support them well at all.
Personally I'd recommend staying away from both of those if you want to use your own custom stored procedures.
July 25, 2009 at 10:35 am
Hi
The main difference between LINQ2SQL and EF is the abstraction layer - in my opinion.
LINQ2SQL (or typed DataSets) is a 1:1 look to the database structure. It is possible to abstract this layer but this isn't the concept. EF (or nHibernate) are ORMs which support a abstraction between database structure and your business layer.
If you want to develop a smaller project you might be faster with LINQ2SQL or typed DataSets. If you develop a larger project you should use EF or nH since you stay more flexible on both sides (server and client).
ORMs (including Linq2Sql and EF) don't support them well at all.
Sorry, but this seems not to be correct. You can use stored procedures or any other custom SQL in most of the new ORMs (including LINQ2SQL and EF).
Greets
Flo
July 26, 2009 at 5:55 pm
Just for the record, I never said they can't support custom stored procedures. I've used them all and getting them to work with custom sprocs is a hack most of the time. Things like multiple resultsets being returned, output parameters, etc.
BTW this doesn't seem like the correct forum for this question anyway.
July 29, 2009 at 8:05 am
Paul_J (7/23/2009)
It's not valid to say "always stored procedures". It totally depends on the application.In any case, unless the stored procedures are plain old CRUD ones then ORMs (including Linq2Sql and EF) don't support them well at all.
Personally I'd recommend staying away from both of those if you want to use your own custom stored procedures.
Implementing appropriate application and database security is nigh-impossible without a "stored-procedures-only" interface layer. A fact that is rarely given the consideration and weight it should early in the design process. While it iis possible to design around this problem when developing tools & utilities, there are very few applications that can do this and still implement security appropiately.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
July 29, 2009 at 6:03 pm
Again, it totally depends on the requirements.
July 29, 2009 at 6:49 pm
Paul_J (7/29/2009)
Again, it totally depends on the requirements.
Again, this is not usually relevant. Generally, stored procedures should be used for applications.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
August 6, 2009 at 2:05 am
A (sort of related) point:-
Unless I'm mistaken, the Entity Framework still doesn't support CLR UDTs on the server. That pretty much makes it a no-no if you're planning on using custom types, or the system-defined CLR types geography, geometry, or hierarchyid (since they look like UDTs to the client)
September 1, 2009 at 1:02 pm
I'm more developer then database fan and i recently read a book "Architecting Microsoft® .NET Solutions for the Enterprise" and i must refer to this sentence in a book:
"If you focus on stored procedures to implement security in a system, you tend to have database people and development people working separately. Security, as stated earlier, is rather more a team sport. So we basically revert to a common point raised by SP advocates who say, "Use SPs if you want good security." If you want good security, this is precisely why you should stop considering SPs as a must-have item. We don't say this because there's something bad about SPs; we say it because having SPs at the center of the universe leads you to making poor design decisions—in terms of security. You can still have SPs, but do not include them for security reasons. And do not include them for implementing logic. Why would you have them, then?".............. and so on.
so i totally agree with this.
and yes use EF for your project.
Sorry for my bad english
September 1, 2009 at 1:39 pm
Hi florim
With new O/R-Mappers (like LINQ2SQL, EF, nHibernate, ...) I don't think the pro or contra procedures is based on security issues any more. They use parametrized statements which avoid any kind of SQL injection and enable execution plans to be reused. These tools are really powerful for fast development.
Just keep in mind that you loose one option in database side: The possibility to reorganize data structures to get always the best performance or storage usage.
Mappers like LINQ2SQL or typed DataSets are a 1:1 mapping of database structure (or procedures) to your business layer. If you use a table based mapping you disable the possibility to optimize the database for new requirements.
Mappers like EF or nHibernate provide a abstraction layer between database structure and client code (business layer) but if the database developer intends to do some changes in table structure you need to supply a new version of your client software to provide a new mapping file. (I think EF 4.0 supports a database stored mapping, what is a important enhancement.)
Greets
Flo
September 2, 2009 at 12:50 am
Yes like i sead before i totaly agree with you.
Sory for my bad english.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply