Creating an Extendable Application with LINQ-to-SQL or Entity Framework

Question

I am working on a framework which will provide some basic functionality for a number of applications which our company is going to develop.

The framework will come with a basic database schema which will support this functionality.

Developers using the framework will be expected to extend the database schema with their own tables. Future versions of the framework will be shipped with update scripts to make any changes required.

What do you think the best way of accessing the database would be - both from within the framework and in the application itself?

I'd like to use either LINQ-to-SQL or the Entity Framework.

Taking LINQ-to-SQL, for example, I guess I could distribute a DBML file with the framework, allowing the application developer to extend it and provide a reference to the data context back to the framework?

Answer 1

I hope that you're using MS Sql in the back-end (though you are if you have Linq To SQL as an alternative).

I have some experience using L2S and some using Entity Framework. In my opinion EF is the better choice because it gives you a better approach towards OR/M and more control over the database objects.

It has full support for LINQ and also for Entity SQL which will give you more power when you need to write complicated queries.

Do NOT think about using EF with MySQL. More about that here

Answer 2

Although it presents some new details, this is still just a versioning issue.

As you develop your system, modifications to the database must be versioned along with modifications to the code. Updates to your system should be an executable package including those database scripts and your data access assembly.

Users that wish to upgrade to the next/latest version must apply the package, which will execute all the database scripts to update the database, and replace the assembly that contains your data access layer. You may want to consider making your DAL a separate assembly for distribution purposes. You could use dependency injection to plug your DAL into your core system.

Depending on the complexity of the system, my fallback would be LINQ to SQL. It performs better overall and is simple to implement. If you expect your object model to get fairly complex, and performance is not a major factor, you may want to go with EF now rather than having to switch later. That's a cost-benefit analysis between performance, complexity, and ease of development.

HTH