Help with logic - system payment method

[netasp]

hi all,
I need your help with the following scenario:
I am using VS 2005 and SQL server DB, my form has 3 textboxes

txtTotalAmount, txtAmountEntere d, txtAmountBalanc e. If txtTotalAmount is
$20.00 for example then user can enter $2.00 in cash, $2.00 in MasterCard,
$16.00 in Cash ,..etc until total amount is reached then balance will show
to user.

I just don't know whats the best way to approach this? store everything in
public variables? public properties? Datatable fields? what is the most
effecient and less overhead call?
If user enters the proper amount, then its easy formula, but when you have
multiple payments (ex: $5 in cash, $5 in Interac, $5 in visa and $20 in
cash - here is the problem!) the LAST $20 in cash is actually ONLY $5.00
that must be added to the cash value for that transaction and $15.00 must be
returned to the customer.

does anyone have a solution for this scenario?

thanks alot

[Jeffrey Tan[MSFT]]

Hi Netasp,

Thanks for your post!

I am not sure I understand you completely. Based on my understanding, you
are developing some payment application with .Net winform, you want to find
a best way to store the values and results efficiently. If I have
misunderstood your concern, please feel free to tell me, thanks.

The solution options you posted are all valid, the choice is based on your
specific scenario and context.

If your application accesses the stored values frequently and your concern
lies in performance side, you'd better eliminate all kinds of disk I/O
storage. Although DataBase is a highly optimized application for I/O
operation, any disk I/O operation will be slower than memory access, so
you'd better store the values in the class variables/properties. There is
no need to mark the variables/properties as public unless certain code out
of the form class needs to access them, I think private is enough for
privacy. Whether you should use variables or properties depends on whether
you want to place any additionally logic around these variables. For
example, in assigning the value to the variable, you want to give it a
validation to ensure the value falls in certain boundary(such as
0=<value<txtTot alAmount), you'd better use a property and place the
validation logic in the property's get/set accessors. At last, you may feel
free to write a logic class to wrap all these variables/properties, this
will make your code easier to maintain.

I see that you are concerning multi-user concurrency accessing the
variables/properties at the same time. In Windows, any instance of an
application will be executed in memory as a process, and multiple running
instances of the same application will be recognized as different
processes, they have different copies of data in memory, so different
users will not have race-condition problem. So if you do not employ
mutlithreading in the application, there will be no concurrency issue.

Ok, normally highly performance is required only by server-side
applications, such as Asp.net/WebService, this is because they will service
tens of thousands of client requests. Regarding .Net winform application,
it normally remains as a client application, which only serves not many
users concurrently. In this case, performance is not a big issue. In this
cause, if you need to store a large number of data, memory usage maybe a
bigger issue than performance. In this case, you'd better store part of the
large data in disk to reduce the application memory footprint. DataBase or
per-user configuration files are both suitable for this. For security
reason(since performance is not the top #1 issue now), I think storing the
values in per-user configuration is a good idea, because the user
configuration file will be stored in windows profiler folder, which is not
accessible to other users(except Administrators, which is the owner of the
machine so he can access everything :-)).

Finally, if your application also has not much concern over memory usage,
you may choose whatever options you like, sure, the variables/properties
way is the easiest to implement.

You may give your application context and condition a judge and choose a
suitable solution based on the text I posted above.

Hope it helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Netasp,

Does my reply help you? If you still have anything unclear, please feel
free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.