Architecture for a DAL
When I say DAL I mean a physical layer that manages connections.
I had a though yesterday. Many people call methods on a class representing the DAL. And they receieve data back from it to populate thier business classes.
I realize there are many different forms of this solution. ( I was a contactor and I saw good examples and nightmares, along with "what the ..." designs )
So I was thinking this. What instead of having classes I call I create delegates that represent all of the work a DAL would do and consumers only called these delegates. This would have many benefits by examining this.
What I want to know is this. Is this an idea with merit? or am I going down a path with a dead end? I'd like some thoughts before I go off on a tangent that just wastes my time.
Nick
[826 byte] By [
nick5454] at [2007-12-25]
(IMHO) As you mentioned and as the old saying goes, "The road to hell is paved with good intentions."...so one must be careful. The best bet
in my view is future extensibility...is it answered by your design?
What I found is that it is best to genericise the actions to such a point to where they can be called by many different clients. For example my favorite methodology is to write my Access Objects where they can stand alone. I can then call them from a Unit test structure which links to them in directly. But for any client, whether it is a webservice or application, must instantiate the AL objects via a factory. The factory only allows communication via Interfaces, with input and and output interfaces defined. Therefore if specific data needs change either incoming or outgoing, it doesnt' break the original data objects created and is extensible.
Note that I also break each of the layers into their own specific projects (DAL)(Factory)(Interfaces)(Business Operations)(WebService)(Winform) since communication is done via interfaces...
I mentioned unit tests, I also have a test for the factory and if a webservice sits in front of the factory, it also has unique tests. That way I can quickly diagnose a problem, is it DAL, or the factory or the webservice? When there is a problem I can zero in on it due to the seperation of all distinct actions.
(Note I override ToString() to report the basic state of Class objects outputted in readable text so each object's state can be viewed during a data dump.)
I know I haven't answered your question, but given you a rule of thumb. Does your design allow for easy updating, maintenance and consumer consumption in the future? Ask those questions and it might lead you to a good design.
Nick, could you explain a little more how do you plan to use delegates to implement the DAL?
Rgds
Rodrigo
Can you please share some sample project of your approach. Thanks
Sorry this took so long. Holidays and birthdays
So heres my thoughts:
Instead of having this DAL as a tangible DLL, I was thinking that I could have something like this.
1) I have a base assembly which we will call "baseAssembly".
Inside that assembly will exists delegates that perform DAL functions like GetMyData()
2) The baseAssembly will be domain neutral so that way, it will always exist in any created AppDomain.
3) using "Assembly.GetAssembly()", The Business Layer will find the assembly and load the reference so it can communicate with the "baseAssembly"
My idea is which ever layer that is decided to call this DAL will just get a reference to the assembly and call the delegates.
My intent is to make the DAL easily accessible without needing to know the "how" of using the DAL.
Does this sound like a good design? If not what are my flaws in this idea? Any criticism would be greatly appreciated.
Thanks,
Nick
What are the major benefits you see by having the delegate approach? Are you trying to break the references to the DAL class itself by using delegates? So the delegates get initialized to point to the DAL methods at runtime and the caller doesn't know what they are calling. If you are going this route, why not just user interfaces with a factory pattern? You can have a static factory method that returns an object that is of type IDAL. Then the apps call the factory whenver they need to get a DAL instance and then just invokes it. You can still use reflection to load the actual DAL instance class. It could be sitting in your assembly or even in an external assembly. This method will allow you to support different DALS for different kind of datasources without requiring any knowledge from the caller.
Thank you for your reply.
I'm not trying to bypass references. My intent was more like using old DCOM. Where the client latches onto the delegates and the delegates transparently find the DAL.
I thought since delegates are basically are callback functions. The caller could use delegates to get synchronous/asymchronous calls from the DAL.
And yes static calls would also work.
I thought that delegates would be better because sometimes the DAL is in a remote place and if I needed to go to a remote place, then the delagete function would handle that transparency.
So which would be a better route? To use a static factory or have consumers attach to the delegates they need?
They both achieve the same thing.
With delegates though they need to manage all the different delegates. That could be a lot of management if you have many different kinds of methods that you are working with. Also the delegate model would be heavier than using interfaces.
How with this model would state be handled? Also would you expect to be passing connection information with each method call?
That was probably the question I was looking for.
Theres just too much info to be maintained to keep it in a delegate without it become a problem in itself.
Thanks for helping me. I'm going to stick with a factory.
Although it sounded like a neat idea.
Thanks,
Nick
Sure thing. The benefit of the factory is that clients just have to know where the factory is and can call it whenever they please. The factory can do caching and maintain references so this way the caller just calls the object and releases the reference when they are done with the work they needed to do.
