When the Linq word begin to spread to the developper’s world, I immediatly inform me about what is it and what can I do with “that”. After trying Linq To Object, Linq To XML, Linq To SQL and Linq To Entity, I was convinced that it was the right path to follow. But for Data management, I was preferring Linq To SQL because Linq To Entity utilisation was boring(Stored Procedure to write).
After SP1, Linq To Entity was not the same. So I studied it more deeper… And some good things falls.
If I must define what Linq To Entity can bring you compared to Linq To SQL, I will say:
- Inheritance
- Complex types
- Define a view like a table(CRUD actions with stored procedures)
The real purpose of Linq To Entity is to define an object conception that will not necessary match to your database shema relationship. A real good thing when implementing your business layer and rules.
In this example, the class UserDB is a copy of the User Table(with Linq To SQL or others code generation tools).
With linq to Entity, we can build your object model with inheritances and rules(User is defined as abstract). So we cannot used a user directly but we need to use the child classes(not abstract). The mapping to get an administrator user is done by the model by auto-filling the required filters. Magic…
I invite the Linq To SQL users to gather more information about Linq To Entity and see the added functionnalities.
