Concerns regarding Linq [modified]
-
Hey guys... i just started Linq yesterday and feel comfortable with the basics(Building entity classes, insert, update, delete, etc) i have a couple of questions tho 1) What happens when the db creation script is altered(lets say a field is added to a table), does the entity classes update automatically? 2) In a larger db (about 85 tables), should i have one dbml file in my project with all the tables and work with that or split it up?. For instance there might be only 3 tables related directly to a user and 2 windows that use its data, should i create a dbml file with only the relevant tables for the relevant windows? 3) how are SQL exceptions handled??? (never mind, i saw
SubmitChanges()throws out the exceptions) 4) i dont see return types on methods likeSubmitChanges()orInsertOnSubmit()to even check that the insert for example actually took place? How can i get similar feedback? 5) can you recomend any good Linq articles from which i can learn more than the basics ive mentioned? <Edit> 6) Where does this leave stored procedures that simply select data? In the application im developing all the db stuff is done with stored procedures, even simple selects. The main reason would be that its pre compiled and it reduces sql injection risk. are injections posible if im using Linq? Any other thoughts on this subject? </Edit> ThanxHarvey Saayman - South Africa Junior Developer .Net, C#, SQL
you.suck = (you.passion != Programming)modified on Wednesday, July 23, 2008 7:25 AM
-
Hey guys... i just started Linq yesterday and feel comfortable with the basics(Building entity classes, insert, update, delete, etc) i have a couple of questions tho 1) What happens when the db creation script is altered(lets say a field is added to a table), does the entity classes update automatically? 2) In a larger db (about 85 tables), should i have one dbml file in my project with all the tables and work with that or split it up?. For instance there might be only 3 tables related directly to a user and 2 windows that use its data, should i create a dbml file with only the relevant tables for the relevant windows? 3) how are SQL exceptions handled??? (never mind, i saw
SubmitChanges()throws out the exceptions) 4) i dont see return types on methods likeSubmitChanges()orInsertOnSubmit()to even check that the insert for example actually took place? How can i get similar feedback? 5) can you recomend any good Linq articles from which i can learn more than the basics ive mentioned? <Edit> 6) Where does this leave stored procedures that simply select data? In the application im developing all the db stuff is done with stored procedures, even simple selects. The main reason would be that its pre compiled and it reduces sql injection risk. are injections posible if im using Linq? Any other thoughts on this subject? </Edit> ThanxHarvey Saayman - South Africa Junior Developer .Net, C#, SQL
you.suck = (you.passion != Programming)modified on Wednesday, July 23, 2008 7:25 AM
HarveySaayman wrote:
- What happens when the db creation script is altered(lets say a field is added to a table), does the entity classes update automatically?
No.
HarveySaayman wrote:
- In a larger db (about 85 tables), should i have one dbml file in my project with all the tables and work with that or split it up?. For instance there might be only 3 tables related directly to a user and 2 windows that use its data, should i create a dbml file with only the relevant tables for the relevant windows?
There are issues with single dbml files. One solution is to create multiple files - another is to create a business layer that manages this; believe me, it's not easy.
HarveySaayman wrote:
i dont see return types on methods like SubmitChanges() or InsertOnSubmit() to even check that the insert for example actually took place? How can i get similar feedback?
Well, with LINQ you can check the conflict resolution[^] to see if there were any conflicts. Other problems would be thrown as exceptions.
HarveySaayman wrote:
- Where does this leave stored procedures that simply select data? In the application im developing all the db stuff is done with stored procedures, even simple selects. The main reason would be that its pre compiled and it reduces sql injection risk. are injections posible if im using Linq? Any other thoughts on this subject?
You don't need stored procedures to prevent SQL injection, you just need parameterised queries. There's always a place for stored procedures, but there's less overwhelming need. However, you can still use SPs with Linq, and this is a good thing. Stored Procs can cope with things that are a lot harder to do in LINQ, plus if there's a bug - it's easier to fix and deploy a stored proc when the code is in production than it is with an assembly.
Deja View - the feeling that you've seen this post before.
-
HarveySaayman wrote:
- What happens when the db creation script is altered(lets say a field is added to a table), does the entity classes update automatically?
No.
HarveySaayman wrote:
- In a larger db (about 85 tables), should i have one dbml file in my project with all the tables and work with that or split it up?. For instance there might be only 3 tables related directly to a user and 2 windows that use its data, should i create a dbml file with only the relevant tables for the relevant windows?
There are issues with single dbml files. One solution is to create multiple files - another is to create a business layer that manages this; believe me, it's not easy.
HarveySaayman wrote:
i dont see return types on methods like SubmitChanges() or InsertOnSubmit() to even check that the insert for example actually took place? How can i get similar feedback?
Well, with LINQ you can check the conflict resolution[^] to see if there were any conflicts. Other problems would be thrown as exceptions.
HarveySaayman wrote:
- Where does this leave stored procedures that simply select data? In the application im developing all the db stuff is done with stored procedures, even simple selects. The main reason would be that its pre compiled and it reduces sql injection risk. are injections posible if im using Linq? Any other thoughts on this subject?
You don't need stored procedures to prevent SQL injection, you just need parameterised queries. There's always a place for stored procedures, but there's less overwhelming need. However, you can still use SPs with Linq, and this is a good thing. Stored Procs can cope with things that are a lot harder to do in LINQ, plus if there's a bug - it's easier to fix and deploy a stored proc when the code is in production than it is with an assembly.
Deja View - the feeling that you've seen this post before.
Thanx pete OT: i still have some issues with the comparing of rows, haven't got the
GetChangeSet()to work like i need it to... yet :). Still have some stuff im gona try but ill pick your brain tomorrow after exploring it a little more. thanx againHarvey Saayman - South Africa Junior Developer .Net, C#, SQL
you.suck = (you.passion != Programming)