|
NOTE: This list of posts will only list the 15 latest posts,
to see the rest, select from the Archives located in the menu to the left. The
RSS will only list the 10 lastest posts.
|
What Data Access technology do I recommend?
|
|
Category:
Design and Architecture
I got several questions about what Data Access technology I recommend. So I decided to write down the answer into a post.
First of all I use a "model-first" approach, which means that I don’t care about the data source. So what I do is first to create my domain model with entities, business logic etc. When the model is done I decide what data source I need to use. The result is often a database. Because I use Domain Driven Design, I also use OR-Mapper to map my model against a database. I don’t use DataSet, I actually never did when .Net arrived. The reason is that a DataSet is more or less a copy of a database. It has Tables, rows and columns. In .Net 1.x the DataSet was a huge object, in .Net 2.0 Microsoft reduce the size of it, but still it has a database like model. I also wanted to use the power of Object-Oriented programming and a DataSet in this case was not an option. I also wanted to make my code easier to read and understand. By using an object like Customer which will have information about a Customer is more logical for people to understand than having a DataSet with relations etc with the information about a customer.
The OR-Mapper I used was my own implementation or nHibernate. But as soon as ADO.Net Entity Framework will arrive, I will probably use it instead of other OR-Mappers (The mapping tools and the final features of ADO.Net Entity Framework will decide if I will use of it.). One sad thing with the ADO.NET Entity Framework is the lack of support for POCOs (We need to implement an interface on all of our entities).
Very soon we will have the possibility to use LINQ to SQL. I know that several people will use it for data access. With LINQ to SQL we can easily by dragging out tables get classes generated and can start using LINQ as a query language against the generated model to get our data. The problem is that the model is created out from a database schema, and a database schema is based on relations and normalization rules etc. So we can’t really generate a domain model out from a database, or we shouldn’t if we use Domain Driven Design. The design of our model should not be decided by the data source. But it’s a very fast technology if we want to speed up our data access development against a database. For small projects where a database is required or already exists from the beginning, I will probably use LINQ to SQL, but it depends on what the application should do. For large applications I will probably not use LINQ to SQL.
With the ADO.Net Entity Framework we will be able to create our own model first and then map it against one or more data sources; we can also use Value objects etc. LINQ to SQL can’t map against several data sources and has the lacks of support for Value objects which I often use in my domain model.
|
|
Posted: Saturday, November 03, 2007 - 13:25 GMT+1
 Print
 E-mail
 Comments (4)
|
|
|
|