Storage of business logic, control properties, data validation on database

Question

0.00/5 (No votes)

See more:

I have a data entry web application that acts as a control manager deciding which other webforms to invoke. Typically, these are different data entry webforms for some other applications.

I would like to shift the existing business logic from backend C# code to stored procedures in database (Oracle). Additionally, I would also like to store the controls'(ie textbox, label) properties (ie x-coordinate, y-coordinate, width, height) in the database such that they are painted on run-time on to the webform based on users selection . For example, if a user selects "Product" then the set of controls relating to Product information is printed. If user selects "Employee" then set of controls relating to Employee is painted.

I forsee some problems such as re-painting of controls on each postback, incurring addtional database calls to retrieve the controls' properties, caching of controls' state in web server would potentially be huge if there are multiple controls and users.

Is there a better design to such an approach? Appreciate some opinions. Thank you.

Posted 22-Aug-10 20:57pm

ronbutan

Updated 22-Aug-10 20:59pm

v2

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Christian Graus · Answer 1 · 2010-08-22T21:03:00

Solution 1

The only reason to store the position of controls in the DB, is to make a system where people can design their own forms. The other issue is, such a system would probably result in forms with absolute positioning, losing HTML's ability to flow for different size screens. Perhaps you could tell us what the benefit is that you expect to get from this ? Either way, you could store the positions on first load and not read them again on postback.

Posted 22-Aug-10 21:03pm

Christian Graus

Comments

ronbutan 23-Aug-10 5:37am

The aim of such a design was actually to eradicate the need for designing and storing muliple data insertion forms for different entities (ie Employee data entry form, Product data entry form). In this case, we will need just one form with controls painted dynamically and upon data insertion, make use of the ID property of each control to determine which database to insert into (ie txtName_Product == Product database, txtName_Employee == Employee)

The information for the controls properties will be pre-loaded by another application or by a DBA.