Data Layer Interface design RRS feed

  • Question

  • Hi,


    I am working on n-Tier architecture. I have P layer, BL, DAL, DAta tier....


    I am working on DAL now and want to expose interface from DAL which BL will use...


    Want to know which should be return type.... thinking of IDictionary but again converting Datatable to IDictionary is a big headache..


    I have read somewhere we should not use DataTable, dataset..rather should use interface.......


    Please guide me..

    Monday, February 11, 2008 1:49 PM





    In this scenario I will suggest you to use Business Entities.



    Tuesday, February 12, 2008 9:49 AM

All replies

  • Well, 
    I had some problems when sending and receiving Datatables in Web services, some characters were lost, since then I prefeer to use Datasets but only when I use datasets, using datatables will consume less memory so I guess its about to you, also you can use some ORM tools and avoid to use datasets and datatables.

    Pedro R.
    Monday, February 11, 2008 11:42 PM
  • Hey BPanic,


    Thanks for the reply.... but I have read somewhere that we should not use DataTable or Dataset as a return type from the DAL....


    we should use some generic interface...........................


    Can anyone have Idea what the best approach could be? I have told my IDictionary problem........


    Waiting for reply............



    Tuesday, February 12, 2008 5:43 AM



    In this scenario I will suggest you to use Business Entities.



    Tuesday, February 12, 2008 9:49 AM
  • HashTable or IList<>...

    Tuesday, February 12, 2008 11:34 AM
  • dont use hashtable use the generic list<T> , its perfect for custom entities such as yours..

    Wednesday, February 13, 2008 2:30 AM
  • Hi,


    Use domain objects, or entities to return the data.  If you have collections, you can use an interface which derives from IList<> so:


    If you object is IPerson, the the IPersonList interface would derive from IList<IPerson>, and the PersonList would implement List<IPerson>.  The reason I would do this is then if you wanted to change the IList to an ICollection, that would be easier than going through using the IList<> directly.


    One thing to bear in mind, if you're using automatic serialization, then you won't be able to serialize any interfaces at all.  there are plenty of ways around that if you wanted to do it, either by not using interfaces, or by implementing your own custom serialization instead, but that's the only gotcha I can think of with doing it that way. 


    From a point of abstraction, I would never want to return .NET framework implementation based interfaces directly, especially if I suspect that they might change, because you then couple a lot of the code to the internal implementation of the Dictionary, or List object, which is the whole point of having an interface?


    You wouldn't use a data table or dataset, because even if it is a typed data set, it is a data object, and means that there isn't the clear separation of layers.  The dataset or datatable is then an entity, but it is an entity that also includes, or may include some data logic, which is quite possibly a maintenance nightmare.  The other thing is that these objects also consist of functionality to make then very flexible indeed, but that comes at the cost of having to send a lot of the framework for that setup back and forth along the wire.  The reasons as above, with interfaces, and coding the whole application to make it work with a dataset is another reason why you would not want to use it.  You want to get data back, and if somehow the implementation of rules change, that should affect your code, or should at least aim to minimize or make it as painless as possible should changes take place.


    You aim with the layers is to logically group together the components into components belonging to presentation, business rules, data persistance, services or whatever, so anything that sits in all layers clearly breaks those rules.  Within your classes you should also aim to provide an interface through which the objects may be called, and nothing other than the interface should need to be known about the class implementation. 


    I hope this helps, as it's a little more than the question you asked.  I just thought you might like some background!


    Good luck,


    Martin Platt.

    Friday, February 15, 2008 4:45 AM
  •  Martin Platt wrote:

    Use domain objects, or entities to return the data.

    Sorry but in this way you will break separation. DataLayer may return data transfer objects. This can be IRecord, IPersonRecord (if one want typed interface) or something like this. Domain objects should not have public visibility of the state. Domain objects should have logic. They should maintain visibility. And so on.


    For example look at visibility. When domain object may have read only property it can, but this is not true for data transfer objects, DTO objects may should have their state full visible.


     Martin Platt wrote:

      If you have collections, you can use an interface which derives from IList<> so:


    If you object is IPerson, the the IPersonList interface would derive from IList<IPerson>, and the PersonList would implement List<IPerson>.  The reason I would do this is then if you wanted to change the IList to an ICollection, that would be easier than going through using the IList<> directly.

    List<T> does not support extensibility. This is recommended to use Collection<T> for such lists.

     Martin Platt wrote:

    You wouldn't use a data table or dataset, because even if it is a typed data set, it is a data object, and means that there isn't the clear separation of layers.

    Why DAL should not return DTO? Any way, I am also will not recommend DataTable, but not for the reason that they are data objects.

    Saturday, February 16, 2008 5:52 PM
  • Mike,


    And your recommendations are???


    I don't see how a domain object with an interface is going to break anything at all?  The domain objects, or entities can still be returned through an interface, and in so doing, only coupling the implementation to a shared interface.  Although in reality you're likely also to need a shared understanding of concrete objects between layers?


    IRecord is unlikely to cut it either, and IRecord isn't very well named, and isn't likely to be strongly typed either.  An IPersonRecord would be better though, and was the approach that I had in mind.


    It doesn't matter if the implementation is List<> or Collection<> as the IPersonList abstracts that detail away from the caller.  I agree in a way with what you are saying about the List<> vs Collection<> but picking one over the other is largely down to the requirements of the system. 


    A dto would seem to be a good approach, one that I have used successfullly in the past.  I would agree with that sentiment.  So why wouldn't you recommend a DataTable then?  I'd say that it has a lot to do with decoupling?  Also I think that they're often overkill for the requirements.


    I'm interested to hear your suggestions.  I don't see any problem with my recommendations being incorrect, so long as you come up with alternatives, so that we can discuss them, and come up with a great solution for the original poster!


    Martin Platt.

    Monday, February 18, 2008 4:02 AM
  • Hi Martin,


    Thanks for your reply..........


    My requirement is to get the data from the database and show it to the UI. Data should not get changed by any other layer.


    so I would not prefer to use Datatable. So I am using custom entity......... and I have made the entities with my interface rather than using Microsoft given interfaces........ only reason for this is I want to use those interfaces in COM... so I can make my interfaces COMVisible........


    Please advise me if I am doing any mistake here...........


    Thanks again.. Smile


    Wednesday, February 27, 2008 5:42 AM
  • Hello,


    Want to know which should be return type.... thinking of IDictionary but again converting Datatable to IDictionary is a big headache..

    IDictionary, and anything with "Dictionary" in its name , is quite a bad choice, because as far as I know these types don't support serialization by default. Even if you write your own, interoperability problems will emerge.


    I have read somewhere we should not use DataTable, dataset..rather should use interface.......

    DataTable have some overhead, but I can think of scenarios, where strongly typed DataTable could be suitable. But these scenarios would include using functionality build in DataTable, so if you don't need this functionality - you shouldn't use it.


    In general I would use data entity, but I'm not quite sure I would design interface for it. Using interfaces for data entities can bring you quite close to "overengineering".


    In general I use interface when I'm planning or expecting to develop different implementations of that interface.

    This is usually not the case with data entities - so I would use a regular class for single record representation, and some type of IList<T> implementation for tables. To be honest I would just use List<T>, because I'm lazy and I'm usually against rewriting code that someone has written for me before .


    I would be careful with arguments like "maybe I will need some changes in the future". It is quite unlikely that complicating your code by adding several abstraction levels will help you in coping with unpredicted changes in the future. I'm not saying that abstraction is a bad thing - it just have to be justified by the very solution you are working on.

    Wednesday, February 27, 2008 9:20 PM

    I think that the approach is generally sound.  I would never use the Microsoft interfaces in code unless they're a 'leaf' class in the hierarchy, because then the solution is coupled to that interface.  An example, you have a requirement to return a collection or list of Person objects, if you use IList<IPerson> you are coupled directly to the IList interface, if on the other hand you use IPersonList interface and that in turn derives from IList<IPerson>, if you want to change to a different interface, such as ICollection, or IDictionary or whatever, you have more control to do so, and in one place.  My view is that the interface should encapsulting fully, and since you don't have control over the IList interface that makes controlling changes difficult. 


    I digress, The interfaces are fine for COM, your only thing to be aware of is serialization of obects that are accessed in the proper way through the interface won't serialize, since you can't serialize the interface.  In this case you would have to use the ISerializable interface to roll your own.  Don't change to not using interfaces to suit the out of the box serialization of the classes, and you will no longer be doing things properly, and will be tailoring your solution to fit an implementation.  Custom serialization isn't too tough.


    If there's anything else that isn't clear, please ask,


    Good luck,


    Martin Platt.


    Thursday, February 28, 2008 12:25 AM
  • Oooh you've asked a question that gets poeple hot and bothered. I would take a serious look at some of the new technologies out there (maybe not fully released yet) such as the ADO Entity Framework (or whatever it's current name is!), Astoria (can't remember the new name for that) is another good example. Even if you don't use them they do a good job at explaining how you might want to package up your entities.

    re: Interfaces, perhaps a slight aside but the people that wrote the .net framework published a very interesting book about how to write frameworks and one of the big lessons they learnt was the inherent problems of using interfaces. They decided to use base classes wherever possible, their reasoning? Well if you must change an interface you *must* change all the clients, whereas with a base class you can provide the default behaviour. Just some food for thought.

    Wednesday, March 5, 2008 1:13 AM
  • Do you think that that is good reasoning?


    The interface is a contract to the clients.  I wouldn't imagine that you'd want to be changing that interface, and should instead be creating a new one that new clients can use?


    If you change the base class, and given your example, you're Microsoft, you would either break everyone's code, or create multiple versions of the same base class, which would seem to be a maintenance nightmare?  Personally I think that there are cases for both approached, depending upon what you're trying to do, frequency of change, and so on.  If the code is likely to change often, you'd probably use a strategy / provider pattern, with a factory to create objects that are swappable through configuration, to manage that change.  Notice though, that the interface would remain?  A base class could also be used in the same way but would effectively be acting as an interface with some implementation provided.


    It used to be the case that a change in a base class would mean a change in all derived classes, but with the advent of .NET it is possible to run side by side versions of the same base class.  I'd imagine that we'd be looking at a nightmare there also, in either scenario, that you're either forced to recompile (not version specific) or forced to maintain and support multiple versions of an implementation?


    I think people have strong views on these sorts of things because the approach can make or break a solution.  The new technologies are good things to look at, I agree with that idea, but wonder if it's a bit of a catch 22 situation, that you don't perhaps understand the new technologies without the good grounding in the basics?


    This certainly is an interesting thread though.  Got me thinking at any rate!


    Martin Platt.


    Wednesday, March 5, 2008 2:08 AM
  • re: Interface vs base class. It is a good topic to discuss, base classes certainly have their limitations, multiple base classes - no. But I do think there are genuine times when you want to change the behaviour of the type (and derived types) without forcing all the clients to update. I think you also need to consider who your clients (for the types) are; if it's internal code then I really favour the base class approach, if it's public then I'd probably lean towards the interface. I added it to the thread because it's worth thinking about rather than claiming it to be any kind of always answer. I'm not even going to consider all these new fangled extender technologies they fill me with dread then we'll get class code everywhere <gulp>.


    I like the point about new technologies, hmm, chicken or egg. You'd hope they'd introduce the new technologies properly but I guess "hope" is key word there!


    Wednesday, March 5, 2008 10:50 AM
  • As always there is no one "silver bullet" solution for all "data entity" problems.


    Currently I'm so "SOA-twisted", that when I hear "client", I assume "service". Developing a service I always desing service interface (as "interface" ) which methods operate on data entities with no behavior at all.

    This is the only way I can assure that all clients, independent of technology they are written in, can consume the service in the same way it was intended for. This separates the client completely from the service implementation, what usually is a good idea.

    In such scenario - where data entities have no behavior, I don't see a point in desinging interfaces for these data entities - they have no behavior, so there is no risk that I will need to change the behavior in the future. And if I have to change entity properties or fields - I would have to change entity regardless it is exposed as an interface or a class.


    In any other case though, when you are going to provide you clients with entities WITH behavior, the situation is different. The question is, if it is a good idea do offer your clients (specially external one) entities with behavior. And again - there is no simple "yes or no" anwer for this question. In projects I was involved in, it usually was bad idea (at least I'm still convinced it was the case ) - but as I've mentioned, lately I work mostly on SOA applications, what implies some design decisions.

    Wednesday, March 5, 2008 11:28 AM

    I'm cringing as I write this (pedant) but, 'And if I have to change entity properties or fields - I would have to change entity regardless it is exposed as an interface or a class.' Maybe not with a class, let me sing the Microsoft Framework song again Wink


    If I have a base class called Person and someone derives from it to create SchoolTeacher. Later on I wanted to add (notice I chose add) HairColor then SchoolTeacher would imediately get HairColor but no code would have to change. Obviously if you wanted to use HairColor you'd have to change but you haven't forced the change. Anyway I'm over egging the pudding now, but you get the idea. PS. Sure this has little to do with Service Interfaces - where the argument just wouldn't stand and therefore perhaps leads to thinking interfaces might be a more generic road to take.






    Wednesday, March 5, 2008 11:37 AM
  • I agree - and to be explicit - I don't prefer using interfaces for describing data entities over classes - the case is just the opposite.

    I'm sorry if I was not articulate enough in this topic, but English is not my first language.


    The sentence you have just quoted ("And if I have to change entity properties or fields - I would have to change entity regardless it is exposed as an interface or a class") was supposed to show that sometimes there is no advantage in using interfaces over classes, so I recommend (and do so myself) to use classes in such cases.


    And using base classes sometimes have advantage over using interfaces of course - there is no doubt in it, but as you've wrote, it has little to do with Service Interfaces and data entities used by them, where general rule is "once published service should never change" and recommended solution is to provide new one and eventually "close" the previous one.




    Wednesday, March 5, 2008 12:05 PM
  • I definitely think that quite a few of the points here are very good points.  I think that I would utilize an Interface when you want a fixed contract and Base class when you are not quite a concerned with a fixed contract.  I think that they both have their places and that you should utilize each where they make the most sense.  If you think that base may change and either you can control the consumer of the class or it won't make a difference to the consumer to add new features then a base class makes sense.  If that is not the case and you truly want it fixed an interface makes sense because it completely outlines the contract that the consumer must use.


    As for utilizing new technologies, there are some very interesting new features coming out with VS 2008 and .Net 3.5 but always make sure to analyze the functionality before relying on it.  As was stated before we "hope" that it is implemented correctly.  Also, be careful because the next best thing in a few months may do away with the old best thing.  Remember the only constant in this game is change.

    Thursday, March 6, 2008 12:05 AM
  • Agreed!  Definitely there are situations where a base class should be used, but as a general rule, I don't think that I'd personally jump in with a base class implementation, certainly not in place of an interface.


    To me, the interface should always be there, and the base class is an option dependent upon the situation.


    Not forcing clients to update without re-compiling, again, I think it depends on where the functionality sits.  If it is a type that the client uses, then the base class will force the clients to be updated.  If it's more a reference class that is instantiated on the server then so long as the interface remains unchanged for the clients, they will be okay.


    My worry is the dangers of having a base class functionality with multiple derived classes.  I know it's down to project control, but you'd need to know what each client did, to ensure that changes to an existing base class would not break their code.  That seems like the introduction of a big risk. 


    I think in that situation, if you suspect that technology, business rules, or whatever is going to change, a provider type pattern with a factory would be the better approach.


    I'm sorry if I sound like I'm going on a tirade, it just read like you were recommending it as the Microsoft approach, and I'd hate for less experienced reader to run with it, without the consideration.  I think our discussions should start that process off for them at least!!


    The point regarding the new technologies was simply that a good grounding in the basics is a good idea before stepping off into something new and getting it completely wrong.  I'd imagine that whilst this is a contentious issue, or could be, readers should know the how's and why's of choosing an approach before adopting a technology that is an unknown at that point.


    Been a good discussion anyway, don't you think?  I think these sorts of discussions are great for less experienced readers of these forums.  Gives them reasoning and hopfully a better understanding.




    Martin Platt.

    Thursday, March 6, 2008 10:33 PM
  • We did a similar solution 3 years ago when we were using .NET 1.1...  The solution was to support layer separation from DAL-BL-UI...  And should be usable in all the layers if needed...


    We arrived at converting all DAL datatables to xml string and our entire solution passed information around different physical layers.  Now our layer binding supports .NET remoting and web service...


    If I were to do the similar solution today, I would use domain entities as suggested by Martin above, especially with the richness of LINQ would make the application pretty slick...




    Friday, March 7, 2008 5:07 AM