Re: application design problem

Thanks for the reply Mihir!

I've looked at the provider model.

I do have one more question.
Let's say I have a Form with two buttons:
When I would click Button1 this sql would execute: "select * from table1"
and when I would click Button2: "select * from table"
(these are just simple examples, equal on Oracle and SQL server. More
complex examples would
have a different syntax!)

I would now have a global Provider object:
Provider p = new SqlProvider();
or
Provider p = new OracleProvider();

in button1_Click I would have this code:
string sql = p.GetStatement(?????);

Here is my question. How and where would I store the sql statements. Have a
table of all SQL statements
in each provider and access them by some form of id?
And write:
string sql = p.GetStatement("Form.button1_Click"); ??

What do you think?

thanks,
saso

ps: I also have questions about my 2. question (regarding different user
controls) but I'll ask that later, when we solve this "problem" :)




"Mihir Solanki" <mihirsolanki@xxxxxxxxxxx> wrote in message
news:198422bb12568c7b7f75aa20cfe@xxxxxxxxxxxxxxxxxxxxxxx
> Hi,
>
> for your second question
> I dont think its a good idea to put all your client spcific logic in UI.
> If tomorrow you get new client then again you have to change your code and
> soon it will be big headache to maintain that kind of code.
>
> Instead I will suggest that you create different Usercontrol for different
> client. By doing that all your Client specific logic will be in
> UserControl only. then at runtime you check which client is active and u
> load that particual UsreControl.
>
> By doing that your Form will be clean and neat. If you get new client you
> just create new Usercontrol and that all.
>
> now you can also simply this problem. Because soon you will have N number
> clients and N*N1 number of Usercontrols in your assembly and there is no
> need of giving X customer, Y cusomer's Usercontrol
>
> so you put all your X Customer UserControls in One Assembly. Y cusomer's
> UserControl in another Assembly and pass them only requried Assemblies.
> Doing that you dont give them what they dont need.
>
>
> If you have heard about Provider Model Pattern then you can use that
> Pattern to solve this kind of problem. Will make your UI easy to maintain
> and will be very extensible.
>
>
> You can use similar logic for your First question as well. Use different
> assemblies for different Databases. have common Interface so all of them
> implements same methods.
> Have a Look at Provider Model Pattern. Basically its a pattern for this
> kind of situations
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp
>
>
> Let me know if I am not clear in explain it.
>
>
> Mihir Solanki
> http://www.mihirsolanki.com
>
>> hi,
>>
>> this is not actually a C# problem but since this is the only newsgroup
>> I
>> follow I decided
>> to post my question here (please tell me where to post this next time
>> if you
>> think this post shouldn't be here).
>> I have two design questions:
>> 1. what is the correct (or best) way to include database queries into
>> the
>> code if you plan on
>> supporting multiple databases. Let's say I have an application that
>> will
>> support SQL server 2000 and Oracle (and maybe even some other
>> database).
>> Where would I store these queries (there could be a LOT of them
>> throughout
>> the entire application)? The queries could be simple, complex, with
>> parameters, INSERT, UPDATE, DELETE statements.... you get the picture
>> :)
>> 2. How to design an application with an extendable user interface?
>> Here is a
>> possible scenario:
>> I make an application for 3 people. After a while, one is really happy
>> with
>> the application and would like to have an upgrade and add just a
>> simple text
>> box (the upgrade could also require another field in the database) but
>> the
>> other
>> 2 clients don't want that textbox. Instead, one of those 2 clients
>> wants 2
>> different fields on the form.
>> How to design the application from the beginning to be prepared for
>> these
>> kinds of changes in the future?
>> For a simple application I could make different copies of the
>> application
>> but even for this simple example I would
>> have 3 different applications - so this solution sound REALLY bad and
>> would
>> probably turn into a maintainance nightmare in a few months.
>> I could also have this:
>> if ( client == "client1") { // show this textbox };
>> but again this doesn't seems very good - it would lead to a lot of ifs
>> in
>> the code.
>> Any ideas?
>>
>> thanks,
>> saso
>
>


.