How to decide which ADO.NET method to use?

I'm pretty new to ADO.NET, and I'm a little confused and frustrated by the number of options available for manipulating data. There's regular ADO.NET, LINQ to SQL, Entity Framework.

Right now I'm developing an IRC client and using ADO.NET (and the SQLite provider) to store settings like networks, servers, favorite channels, etc.

How can I decide which to use?

Edit: One other thing that I need to do that I thought I should mention, is "bind" settings to a GUI in order to edit and manage them. For instance, a settings dialog with networks and setti开发者_运维技巧ngs in a TreeView on the left and textboxes on the right to edit them.

---

First of all, Linq-to-SQL is for Microsoft SQL Server only - so in your case, that option is out the window right away.

Next, I guess you really need to decide how tricky and how complex your data access will be.

If you're mostly dealing with a few tables, each containing a couple of columns, and you need to read and write a few bits of information back and forth, then you're probably best off with standard, straight up ADO.NET (things like the ADO.NET connection and command object to execute SQL queries). In this scenario, it's up to you to handle all "translation" between the relational model (the rows and columns in your database), and the objects you have in your app - it's a bit of gruntwork and a bit of repetitive coding at times - but it works, it's fairly easy for simple scenarios, and gives you the best foundation for understanding ADO.NET's inner workings (if you're fairly new to it).

The ADO.NET Entity Framework and Linq-to-Entities is quite a different beast - and quite a bit more complex. It really shines when you have very large apps, with dozens or hundreds of tables in your database, a big and possible complex business object model in your app, and you need to support all sort of backends (SQL Server, Oracle, Postgres etc.). The EF allows you to define the mappings between the objects (your "Customer" class with its properties) and the relational storage in the database (your "Customers" table with its columns) in a designer, and EF will handle a lot of the grunt work of mapping between tables and your domain objects for you - but it's a lot more to learn, for sure.

So in your case, with a fairly simple app, I'd definitely recommend using just plain old ADO.NET for now, to get to know the ropes and get a feeling for how it works. I don't think going the EF route is worth the trouble and the learning curve in your case.

Marc

---

I really don't understand why you need ADO at all. Why not just use the built in settings persistence framework of .NET? This stores your settings as XML files on a per user basis automatically.

See: http://www.devx.com/dotnet/Article/33944

---

For the lightweight work you are doing, LINQ with a SQLite provider would be an excellent fit in my opinion.

To elaborate:

If you were doing a very-data-heavy application, ADO.NET may be your best for performance vs usability.

However, if you need to do advanced things like querying from multiple data sources, business layer validation or audit injection, Entity Framework is probably your best bet.