To LINQ or not to LINQ

[cptHotkeys]

Hi, I am writing some software which is heavily dependent on a database, the coder who started the project and has since disappeared off face of the earth, he wrote part of the project using Silverlight, LINQ and the entity framework.

The database will need regular modification and additions of both tables and fields. New classes will be needed and existing classes will need modifications also, this will cascade through to the user interface, so all three tiers will need regular additions and modification. (This is required to meet new customers needs, industry standards and government legislation)

How well does LINQ and the Entity Framework suit this kind of scenario?
Am I better off doing the coding the old fashioned way, write my own classes for data access using SQL statement strings and create my own classes to represent the database objects and functionality (which i am more familiar with)?

My little understanding of LINQ and the Entity framework tell me that they are going to make updates, modifications and additions more cumbersome than if I done the work the old fashioned way, correct?
This is my first project that uses LINQ and Entity framework so my experience with maintenance is nil.

[techgnome]

You're not going to like this answer because it doesn't really answer your question, but ...

It depends. Do you have the time to put in the effort to learn LINQ and EF? (Learning LINQ even at a rudimentry level would be beneficial at least... it has uses beyond just data extraction from a database)

No matter what, when the database changes code in the app is going to need to change. When that happens, how critical is it to get it turned around? If you have the time, it might be worth the effort to learn LINQ & EF and use that... since that's what the app is using now. But if it has to be turned around quickly, and you're stronger with the "old fashioned" way (although, I would call it the tried & true way, not "old") and can get it done faster that way, it might be worth it to do it that way, while learning LINQ and EF on the side.

Also, don't look at them as either/or ... each one is another tool in your tool box. Use the right tool for the right job.

-tg

[cptHotkeys]

Thanks for putting things into perspective, Learning linq and EF is something im doing now at a snails pace.
I will devote all my time to LINQ and EF if its capable of providing a dynamic solution which is easier to maintain in the long run.
At the moment im just stressing heaps and coding none, which is great for business aye

I would like to create a plugin system to allow connection to any kind of database with .net support. This is not essential but i have done it before and it worked great with a simple interface called IConnectionManager with four main methods Create, Read, Update and Delete. Nice and simple. I doubt this kind of thing is possible while using EF?

I used to use System.Reflection for this, is there a new way of doing it(I have been absent from programming for a few years)?

Also whats the peoples opinions of EF and LINQ, as a newbie to it all, it seems like an abstracted endorsement to laziness and a compromise on control of your code, am I full of it (maybe I have an aversion to learning) or is there some merit to my opinion?

[techgnome]

LINQ is nice in that it is actually database agnostic... I used it at my last job a lot... going against object collections. We would use the standard customized DataAccess methods (ala table adaptors & datatables) and then used LINQ against that to perform calculations and to extract subset data - without the need to make another trip to the database. To this end, what I learned/used was functional LINQ where we used lambdas. The other side of LINQ is the semantic version... the type that looks like a dyslexic SQL statement (the FROM clause comes first, the SELECT last, unlike SQL, where SELECT is first, then the FROM).

if your modules are always going to have the same signature, or you want to enforce the module's signature, look into interfaces. Then anything that implements that interface is guaranteed to have a Create, Read, Update, etc....

There are a number of ways to architect something like this, they have their pros and cons, some make sense, others don't, and largely, again, depending on the design and intent and context, what works for the goose may not work for the gander.

"it seems like an abstracted endorsement to laziness and a compromise on control of your code" -- yes and no... you are correct, if you want strict control over your data & code, then EF isn't the way to go (I still think learning LINQ though is valuable... as I pointed out, it's not exclusive to dealing with databases... it will work against DATA in general) ... BUT... in this day and age, it's less about control and more about productivity and speed... EF can get you from 0 to 60 a lot faster (if you listen to the sales pitch) than coding it your self... also it gives you datasource agnostic classes. In the end, as a developer, you don't care (or shouldn't care) if the data came from Excel, Access, SQL Server, XML or a flat file. All you know is that you have a collection of Book classes, which each come with a collection of Author classes. And when you want to save the book, you call the class's "Save" method. That's it... let something else deal with the data access portion... Allegedly (I haven't used EF, so I don't know for sure) changing the data source form say SQL Server to Oracle is as simple as swapping out one piece for another... your code goes largely untouched.



-tg

[kareninstructor]

I believe anyone who is considering using LINQ and Lambda should take the time to learn them past the basics to know the strengths, limitations, constraints and advantages/disadvantages. Techngome’s statement “don't look at them as either/or ... each one is another tool in your tool box. Use the right tool for the right job.” Is how you should look at these tools.

I tend to use LINQ and Lambda often more with XML operations than anything else mainly because when done right code is easier to read using LINQ and depending on the task at hand more efficient but not always, again it depends.

If the EF worked with IBM-DB2 I would use it but alas it does not. When working MS-SQL server I use dbContext which is seldom.


For the basics http://msdn.microsoft.com/en-us/vbasic/bb688088.aspx and http://msdn.microsoft.com/en-us/data/aa937723

[cptHotkeys]

Thanks again for your time thoughts, I should stop thinking of LINQ as something that goes hand in hand with EF.
I think I will put my head down and learn them both inside out and stop moaning.

Thanks for the replies

If I make the plugin system that will work with EF I will post it on the appropriate forum.

[Bill Crawley]

Just to throw a curve ball into the design:

I would like to create a plugin system to allow connection to any kind of database with .net support. This is not essential but i have done it before and it worked great with a simple interface called IConnectionManager with four main methods Create, Read, Update and Delete. Nice and simple. I doubt this kind of thing is possible while using EF?

Might be worth taking a look at MVC.