Friday, 19 October 2007

VISUG-devmatch 18/10/2007 - Datasets vs. OO

During this evening event , the Belgian Visual Studio user group ( invited two speaker to present their views regarding datasets-oriented development and a more object-oriented way of working respectively.

Kurt Claeys (Ordina) was the advocate for the dataset approach while Yves Goeleven (Compuware) "preached" the Domain-Driven Design(DDD) way. Both did a good job !

Benefits (What did I learn)

  • Use dataset-approach in application that needs to be build fast.
  • Use dataset-approach If you are more at ease with the relational model than OO-models.
  • Use a dataset to persist information on a PDA . You can use the dataset xml features for that.
  • Check out the new dataset features in VS2008 . You can separate the generated TableAdapters from the dataset type in different projects. So you make a assembly with dataset types that are shared on several layers and/or tiers. There is also a "manager" that handles multi-table updates.
  • Microsoft continues to invest in Datasets (VS2008 , LINQ to Datasets).
  • But Microsoft also tries to keep up with the DDD camp (Entity Framework)
  • There is also stuff in between LINQ to SQL
  • Domain-driven design(DDD) is object-oriented design with emphasis on the problem domain. The domain model is the basis. I should catch up on that (
  • DDD is difficult. Expect big learning curve.
  • Don't expose domain layer immediately to UserInterface layer. You should consider other objects to transport the information of an entity (DDD for principal domain object representing something valuable for the business (customer order, etc).
  • Use an ORM to help you bridge the Object-Relational mismatch
  • You need involvement from all stakeholders to do DDD to practice the Ubiquitous Language principle.

Concerns (What did I miss)

  • Example of DDD applications (or parts of ) to see side-by-side difference. Kurt prepared a lot of example applications to support his viewpoints.

Best regards,



johan andries said...

An OR Mapper like (N)Hibernate is indeed an important tool to do successful DDD, but I would also add dependency injection and AOP (e.g., Spring.NET) as extra enabling technologies. They help to keep the code readable by separating the business code from the technical plumbing (logging, transactions, exception handling).

anowak said...

Another "tool" mentionned in the discussions was something to map object that were used for transportation into a client side oriented object model (OO-mapping).

According to Yves Goeleven it was a best practice not to expose the domain model to the User interface layer.

So I wonder if I don't overmodel my app doing so : 1 domain model, Object/collections for transport and one client-side model.

Could you put some light on this organisation in for example a winforms app that connects to a web-service application ( smart client if you like)?

web application development said...

i totally agree with johan
Hibernate has been indeed a quite wonder model to do catch up with Domain Driven Design.