Is LINQ the best technology for my application
-
Hi, Iam currently looking at a number of Data Access / Persistance frameworks and trying to establish if they are appropriate for my application. One of these is LINQ to Entities. My application is a medium - largish sized enterprise software platform that is being written in C# and being built upon a legacy SQL2000 database. One problem I have is the legacy database has no enforced relationship integrity (Foreign Key constraints) meaning that all integrity checking / mapping is currently done with adhoc SQL in the program code. Further to this a integer identity variable has been used as a surrogate primary key for every primary key column and iam not sure how LINQ will cope with this either. I know with standard ADO.net I would have to select @@scope_identity to get the ID of a recently inserted row so I can then use that in another table elsewhere in the same scope of program code for building relationships - which is obviously a pain. My concern with using LINQ with a legacy DB like this is "how will Linq cope with having no enforced relationships in the DB?". I have been told that we cannot change the database schema / design in anyway as we have too many customers dependant on the current design and it could cause massive problems if we did. Also I would like to understand how linq will cope with building relationships that our based on int identity primary keys. I should probably mention the existing application is 15 years old and has been written in VB6, hence our desperate need to rewrite the program code with more contempory technology patterns and methods. Iam sure non of these concerns are new and I would really like to draw on the experience of some of the LINQ developers on this message board who have had similar experiences! Thanks for your help in advance guys! Mike
-
Hi, Iam currently looking at a number of Data Access / Persistance frameworks and trying to establish if they are appropriate for my application. One of these is LINQ to Entities. My application is a medium - largish sized enterprise software platform that is being written in C# and being built upon a legacy SQL2000 database. One problem I have is the legacy database has no enforced relationship integrity (Foreign Key constraints) meaning that all integrity checking / mapping is currently done with adhoc SQL in the program code. Further to this a integer identity variable has been used as a surrogate primary key for every primary key column and iam not sure how LINQ will cope with this either. I know with standard ADO.net I would have to select @@scope_identity to get the ID of a recently inserted row so I can then use that in another table elsewhere in the same scope of program code for building relationships - which is obviously a pain. My concern with using LINQ with a legacy DB like this is "how will Linq cope with having no enforced relationships in the DB?". I have been told that we cannot change the database schema / design in anyway as we have too many customers dependant on the current design and it could cause massive problems if we did. Also I would like to understand how linq will cope with building relationships that our based on int identity primary keys. I should probably mention the existing application is 15 years old and has been written in VB6, hence our desperate need to rewrite the program code with more contempory technology patterns and methods. Iam sure non of these concerns are new and I would really like to draw on the experience of some of the LINQ developers on this message board who have had similar experiences! Thanks for your help in advance guys! Mike
Mr Jen Withers wrote:
My concern with using LINQ with a legacy DB like this is "how will Linq cope with having no enforced relationships in the DB?".
It will cope well - if you have no database referential integrity, you can still add the relationships at the LINQ end. It's just code after all, and you can manually add relationships that must be honoured in the LINQ designer.
Mr Jen Withers wrote:
Also I would like to understand how linq will cope with building relationships that our based on int identity primary keys.
LINQ copes with these with no problems. As you can immediately get at the key following a call to
SubmitChanges();"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Hi, Iam currently looking at a number of Data Access / Persistance frameworks and trying to establish if they are appropriate for my application. One of these is LINQ to Entities. My application is a medium - largish sized enterprise software platform that is being written in C# and being built upon a legacy SQL2000 database. One problem I have is the legacy database has no enforced relationship integrity (Foreign Key constraints) meaning that all integrity checking / mapping is currently done with adhoc SQL in the program code. Further to this a integer identity variable has been used as a surrogate primary key for every primary key column and iam not sure how LINQ will cope with this either. I know with standard ADO.net I would have to select @@scope_identity to get the ID of a recently inserted row so I can then use that in another table elsewhere in the same scope of program code for building relationships - which is obviously a pain. My concern with using LINQ with a legacy DB like this is "how will Linq cope with having no enforced relationships in the DB?". I have been told that we cannot change the database schema / design in anyway as we have too many customers dependant on the current design and it could cause massive problems if we did. Also I would like to understand how linq will cope with building relationships that our based on int identity primary keys. I should probably mention the existing application is 15 years old and has been written in VB6, hence our desperate need to rewrite the program code with more contempory technology patterns and methods. Iam sure non of these concerns are new and I would really like to draw on the experience of some of the LINQ developers on this message board who have had similar experiences! Thanks for your help in advance guys! Mike
Mr Jen Withers wrote:
One problem I have is the legacy database has no enforced relationship integrity (Foreign Key constraints)
I hate it when you inherit databases like this. It's almost impossible to add them after the fact, especially as there typically is no documentation. :mad:
Kevin
-
Mr Jen Withers wrote:
One problem I have is the legacy database has no enforced relationship integrity (Foreign Key constraints)
I hate it when you inherit databases like this. It's almost impossible to add them after the fact, especially as there typically is no documentation. :mad:
Kevin
thanks for all the replies guys. Legacy Databases are a huge pain - ive got all kinds of things like tables that link back onto themselves and lots of other nasties. My head i rammed full of patterns at the moment trying to decide if I should be abstracting my problem domain into domain entity objects or just trying to implement some simple DAL objects that provide the functionality i need...Why is finding answers always sooo hard.
-
Mr Jen Withers wrote:
My concern with using LINQ with a legacy DB like this is "how will Linq cope with having no enforced relationships in the DB?".
It will cope well - if you have no database referential integrity, you can still add the relationships at the LINQ end. It's just code after all, and you can manually add relationships that must be honoured in the LINQ designer.
Mr Jen Withers wrote:
Also I would like to understand how linq will cope with building relationships that our based on int identity primary keys.
LINQ copes with these with no problems. As you can immediately get at the key following a call to
SubmitChanges();"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
thanks for taking the time to reply - I will put two big ticks in the Linq box :-)