Apr 29, 2010
Sorry i just read the complete post, so I have to update.
I don't see much room for a generic base behavior in your case. Let's take an example of getting Data.
server.GetData(string uriOrFilePathOrQueryStringEtcEtc) but what will it return. Let's say you choose XML, so it will be able to cover hierarchical nature of your ftp directory structure, as well as the result of a query from Sql Server. Ok case handled.
What about renaming a file. Renaming a file is totally different from updating a record. parameters are totally different from each other. Ftp will include other operations like server.MakeDirectory, server.UploadFile
To make all these servers adhere to a standard interface, we may end up writing a very very tricky code, I think what you were thinking of was something like this
and then make up you concrete servers on this basis. and then implementing your concrete servers like
The problem I see is too much different parameters, and disagreement on a base interface, which rules out the application of factory method. Now as far as Strategy is concerned, I see the same problem.
Apr 27, 2010
Sorry but I'm very new in this world (Design Patterns), and now I'm very confused :-(!
I don't understand if the solution is Strategy Pattern or Abstract Factory Pattern.
Apr 27, 2010
I don't understand if that's the correct/right pattern for my problem, but sure, I'm here for learn.
After the application starts, and after the server selection has taken place, the app is always connected to the server. The user can perform different operations, for example, add data (a file or directory if we are connected to an FTP server) or add a value to a table (if we are connected to a SQL server).
Plus, I need a global access to the server class, like a Singleton, because it will be accessed by serveral classes throughout my application.
You presented a nice solution and the Strategy Pattern looks very interesting.
So, am I right to think that I will need a Singleton 'wrapper' class?