Converting a 2-tier application to 3-tier application

[Shantanu Bhattacharya]

Hi,

I have a 2-tier application that allows the end user to create a form
containing controls of the user's choice. The same user can then
populate the database by entering data created using the form he
created. I have to convert this 2-tier application to a 3-tier
application.

Since the form is created on the fly, all the information related to
the controls is also stored in the database. So, there is a lot of
information related to the controls, their sizes, their placement
which is UI information. Further, there is information related to the
data type that each control is representing which corresponds to the
application specific data. Finally, the data pertaining to database
calls is database specific part of the code. Now, even though this
distinction of three layers seem logically very easy, it is very
difficult to translate this into code. That is because the data
structure that would store the information entered in the controls
would have to processed at all the layers, viz. UI, application and
database( or so I perceive). More specifically, the UI layer would
have to contruct the data structure with all the values, the
application layer would have to process it and finally the database
layer would have to process it again to make a single insert call into
the database using ADO. Of course, I could send the value of each
control separately from the UI layer to the App Layer to the DB layer.
But this would make things very very slow that I dread.

Is there any way to do this in more clean way such that this data
structure is processed only in the App Layer and the other layers are
sheilded off this information?

Any input in this regard would be useful.

Regards
Shantanu

 

[Malcolm]

More specifically, the UI layer would
have to contruct the data structure with all the values, the
application layer would have to process it and finally the database
layer would have to process it again to make a single insert call into
the database using ADO. Of course, I could send the value of each
control separately from the UI layer to the App Layer to the DB layer.
But this would make things very very slow that I dread.

Try comp.programming.

I don't see why passing data down three layers should make the code
particularly slow, unless they are on different computers.

Allow the user to edit data to his heart's content, then click on an "apply"
button or something similar to flush it all down to the database.
Since your data structures are generated on the fly, obviously this will
have to be some sort of bytecode - using text would be most maintainable,
but also quite a slow method.

 

[Christopher Benson-Manica]

I have a 2-tier application that allows the end user to create a form
containing controls of the user's choice. The same user can then
populate the database by entering data created using the form he
created. I have to convert this 2-tier application to a 3-tier
application.

etc.

The welcome message below applies to comp.lang.c. This post, however,
isn't topical in comp.lang.c++ either (unless I am grievously
mistaken). If the post is topical in c.l.b.v.m, please direct
followups there. In any case, readers of comp.lang.c would appreciate
being removed from the crosspost list. Thanks. (Followups set to
c.l.b.v.m.)


(The below welcome text was originally written by Ben Pfaff)

Your question is outside the domain of comp.lang.c, which discusses
only the standard C programming language, including the standard C
library. This is a remarkably narrow topic compared to what many
people expect.

For your convenience, the list below contains topics that are not
on-topic for comp.lang.c, and suggests newsgroups for you to explore
if you have questions about these topics. Please do observe proper
netiquette before posting to any of these newsgroups. In particular,
you should read the group's charter and FAQ, if any (FAQs are
available from www.faqs.org and other sources). If those fail to
answer your question then you should browse through at least two weeks
of recent articles to make sure that your question has not already
been answered.

* OS-specific questions, such as how to clear the screen,
access the network, list the files in a directory, or read
"piped" output from a subprocess. These questions should be
directed to OS-specific newsgroups, such as
comp.os.ms-windows.programmer.misc, comp.unix.programmer, or
comp.os.linux.development.apps.

* Compiler-specific questions, such as installation issues and
locations of header files. Ask about these in
compiler-specific newsgroups, such as gnu.gcc.help or
comp.os.ms-windows.programmer.misc. Questions about writing
compilers are appropriate in comp.compilers.

* Processor-specific questions, such as questions about
assembly and machine code. x86 questions are appropriate in
comp.lang.asm.x86, embedded system processor questions may
be appropriate in comp.arch.embedded.

* ABI-specific questions, such as how to interface assembly
code to C. These questions are both processor- and
OS-specific and should typically be asked in OS-specific
newsgroups.

* Algorithms, except questions about C implementations of
algorithms. "How do I implement algorithm X in C?" is not a
question about a C implementation of an algorithm, it is a
request for source code. Newsgroups comp.programming and
comp.theory may be appropriate.

* Making C interoperate with other languages. C has no
facilities for such interoperation. These questions should
be directed to system- or compiler-specific newsgroups. C++
has features for interoperating with C, so consider
comp.lang.c++ for such questions.

* The C standard, as opposed to standard C. Questions about
the C standard are best asked in comp.std.c.

* C++. Please do not post or cross-post questions about C++
to comp.lang.c. Ask C++ questions in C++ newsgroups, such
as comp.lang.c++ or comp.lang.c++.moderated.

* Test posts. Please test in a newsgroup meant for testing,
such as alt.test.

news.groups.questions is a good place to ask about the appropriate
newsgroup for a given topic.