Re: application design problem

Thats right,

UI or DataProvider doesnt need to know about database or queries or anything. they just provide functionality. Actual action is depends on your Provider which provide service for a particual database or data store.

ya so u need something like that
DataProvider.InsertIntoSomeTable(string value1, string value2)
or update
DataProvider.UpdateSomeTable(and required parameter inputs)
or delete
DataProvider.DeleteFromSomeTable(int id (or required inputs))



Mihir Solanki
http://www.mihirsolanki.com

Ok... I understand.

And the other statements would be the same?
e.g. INSERT into table X (col1,col2) values (...)
so you would have
DataProvider.InsertIntoSomeTable(string value1, string value2)
?
"Mihir Solanki" <mihirsolanki@xxxxxxxxxxx> wrote in message
news:198422bb13ea8c7b83de1430268@xxxxxxxxxxxxxxxxxxxxxxx

Yes ofcourse there is lots of methods in that dataprovider class but
that is the only way you can seperate your UI and Data access layer.

Yes in starting you may find that for a single one method you are
implementing 4 different methods but after sometime you will really
feel
that your life became easy by doing such thing. Easy to maintain,
easy to
write code (2 developers can work at same time on 2 different model.
i.e
one for sql and one for oracle), easy to extend (i.e if somebody come
tomorrow and say I want support for MySql, then you will say its half
a
day job as you will have working UI and you just need to implement
MySqlDataProvider, just few methods and most of them copy and paste
from
your existing providers.
Not only my company but there are lots of companies they hvae similar
models. Even look at microsoft Asp.net 2.0. It is full of provider
model.
Mihir Solanki
http://www.mihirsolanki.com

thanks again for all the help...

here's my question about the way that your companies uses this
model.

Doesn't your DataProvider abstract class have LOTS of methods?
The method seems very appealing but it seems that I would soon get
lost in
all the methods.
What do you think?
"Mihir Solanki" <mihirsolanki@xxxxxxxxxxx> wrote in message
news:198422bb12d68c7b80b17329aec@xxxxxxxxxxxxxxxxxxxxxxx

k you can download demo from my website here

http://www.mihirsolanki.com/ProviderModelDemo.zip

Mihir Solanki
http://www.mihirsolanki.com

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/
dn
as
pnet/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



.