C# Data Layer and Dto's

Question

I have recently joined a company that using typed datasets as their 'Dto'. I think they are really rubbish and want to change it to something a little more modern and user friendly. So, I am trying to update the code so that the data layer is more generic, i.e. using interfaces etc, the other guy does not know what a Dto is and we are having a slight disagreement about how it should be done.

Without trying to sway people to my way of thinking, I would like to get impartial answers from you people as to what layers the Dto can be present in. All layers; DAL, BL and Presentation or a small sub set within these layers only.

Also, whether IList objects should or should not be present in the DAL.

Thanks.

Answer 1

One thing is DataSets are poor to achieve interoperability. Even typed datasets are also not so compatible when it comes to consuming typed datasets from a non .net client. Refer this link. If you have to achieve interoperability then fight hard for DTOs otherwise try to make your team understand DTOs over a period of time because datasets are not so bad after all.

On part of interfaces, yes you should be exposing interfaces. For example - If you are returning List<T> from DAL, instead you should return IList<T>. Some people go to extent of returning only IEnumerable<T> because all you need is capability to enumerate. But then while doing it don't become astronaut architect.

In my applications I have figured out that returning IList<T> instead of List<T> pollutes my code base with codes like this:

//consider personCollection as IList<Person>
(personCollection as List<Person>).ForEach(//Do Something)

So I personally try to maintain a balance between returning interface or concrete object. If you ask me what I am doing right now, then I will tell you I am returning List<T>. I am influenced to not to become astronaut architect.

Answer 2

I always use DTOs, never DataTable. But I only use them to transfer from BL to DL and the other way around. My presentation layers are often only aware of the business and service layers in case of service oriented.

The benefits I can see to use DTOs rather than datatables:

• easy refactoring
• easy diagram production
• cleaner more readable code, especially in the DAL's unit tests

Answer 3

By definition a DTO is a data transfer object, used to (wait for it) transfer data from one layer to another.

DTOs can be used across all layers and I have used them well with web services.

Answer 4

It really depends on your architecture.

For the most point you should try to code to interfaces then it doesn't really matter what your implementation is. If you return ISomething it could be your SomethingEntity or your SomethingDTO but your consuming code doesn't care less as long as it implements the interface.

You should be returning an IList/ICollection/IEnumerable over a concrete collection or array.

• Properties should not return arrays
• Do not expose generic lists

What you should try to do first is separate your code and make it loosely coupled by inserting some interfaces between your layers such as a repository for your DataAccess layer. Your repository then returns your entities encapsulated by an interface. This will make your code more testable and allow you to mock more easily. Once you have your tests in place you can then start to change the implementations with less risk.

If you do start to use interfaces I would suggest integrating an IoC such as Windsor sooner rather than later. If you do it from the get go it will make things easier later on.