Simple Data – Example with compare

compare-ef-and-simple.data

Simple Data

Simple.Data is dynamic ORM. But What mean ORM : O – object, R – Relational, M – Mapping. But if simple data is dynamic we haven’t objects, relationals, mapping. So try again „Simple.Data is dynamic (NullReferenceException)” – weak joke 😉

Today I will try to compare Simple.Data with EntityFramework.

Example

The example uses two tables „team” and „players”

example

For example code has been written in console and to measure execution time I use Stopwatch class. It’s look like:

Loading data

Let’s try to load data from database with Simple.Data. It’s so simple, we serve as parametr our connection string to our database in method .OpenConnection() we can also use .Open() method if we configured connection string in App.Config. Method defaultDb.Team.All() return all records from table team.

And the same in Entity Framework.

Test look like:

compare ef and simple data

The result are very similar. Try to add join to our query.

Simple.Data join:

ORM join:

Result:

compare ef and simple data

Here we have five records and time is five times bigger.

Insert

Let’s see the diffrence in the insert.

Simple.Data

ORM

Result

compare insert ef and simple data

And again we see the difference in the times between Entity Framework and Simple.Data.

Summary

Writing code in a simple.data looks more intuitive and is faster then EF. But the cost of this it is the lack of intellisense because we operate on dynamic variable. Any syntax errors are detected only after run applications. Plus is the simplicity of the writing unit test and perform faster then those that are based on eg. entity framework. A unit test example with Simple.Data.

If you are interested in library simple.data here is documentation.

Link to this project.

Addition

Lazy loading vs eager loading vs simple data

I added a loop to measure time with eager loading.

eager loading vs lazy loading vs simple data

6 Comments on “Simple Data – Example with compare”

  1. My suggestions:
    1. in first example of EF you should materialize rows retrieved from db, for example:
    var listEF = db.team.ToList();

    2. you should do many tests (for example 10 in loop) to avoid „cold code”,

    3. I liked SimpleData, but I see problem with the project that seems lost: for example a year ago when I tried to use it I could’t find Oracle connector to SD that used current version of Oracle driver.

    1. Yeah.
      Another thing is .AsNoTracking() ( or something like that, don’t remember the name) which lets you ignore tracking for these records (perfect for queries).

      So in this case the magic line should be:
      (from a in db.team
      join b in db.players on a.ID equals b.ID_team
      select b.Surname).AsNoTracking().ToList()

      Your approach to adding/inserting in EF is also the most easy and non – performant.
      The optimized way is to attach newly created entity to context and just mark non default properties as changed.

      In case of multiples of entities one would go with BulkInsert as well.

      That is an enterprise way of using EF. If you are using it like you are presenting… you are doing it wrong. 😉

      1. Another problem of that blog post is a total ignorance of the real ORM to sql performance problems… which is how these ORMs are building queries and how that affects query execution plans.

        PS. Support for mapping of stored procedures is in many aspects also crucial… EF fails here quite miserably.

        1. 1.I agree that I should use .AsNoTracking(), but just in case only if I want to display data, otherwise if I want to edit this data later it is recommended to use the default query, mean without .AsNoTracking().
          2.I wrote a post that shows how generated is sql in eager loading and lazy loading here, and if someone want to see how generated is sql in simple.data this is written in the documentation here

    2. In part with the addition I added loop and I removed the effect of „cold code” also I added eager loading, lazy loading to list().

  2. If you have lazy loading enabled in EF (by default s fast as I remember), then I guess your join comparison may be flawed. Have you tried to use .Include() method to say what tables should be eager-loaded? This may affect Entity Framework performance results. Also, how does Simple.Data handle transactions? It may be interesting to try to insert many entities within the same transaction. The performance comparison result may say a bit more about usage of these libraries in more real use cases.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *