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

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.