Best practices for distributed app?

Best practices for distributed app?
I am working on a tracking/inventory system for a factory.

Here are the specs:

1. The factory will have a server with a DB and five computers connected to the server through a wireless network.
2. Three of the computers will have barcode scanners connected to them with USB cables.
3. All computers need to connect with the DB.
4. All computers need to have access to up-to-date information.

Since this is a one man project, I have already done the DB, Data Access Layer, and the business objects layer. I am also working on the UI.

But since I have only done single computer apps, I am unsure of the best practices for this situation.

Here are some specific questions:

1. How do I manage user log ins–per computer, or for all the computers?
2. How do I prevent two users from corrupting one object?
3. Can I use events to notify the various computers of activities on the server?
Thanks again for any help. I’ll do my own coding, but I just need some guidance to start with
Thanks for the help Einstein! I have a good start to work with.

Best answer:

1. How do I manage user log ins—per computer, or for all the computers?

I don’t understand this question.

Are you asking where should the authentication/validation be done? Can a particular log on from any machine on the network? Are you referring to security or technical considerations? If the user can “float” around to various machines, then a centralized validation schema should be set up. What if the user’s computer must have its OS re-installed? Then, everything, including the user’s login profile must be recreated if you are don’t keep the information on a central computer.

2. How do I prevent two users from corrupting one object?
One of the most important considerations for any multi-user application is record locking. (Ideally, you would want to be able to have a level of granularity where you could lock at the field level.) The program must not allow two users to try to edit the same record at the same time. Some database or programming features may prevent one user from overwriting the changes made by the other, but it will only do that when the second user tries to save his/her changes to the datbase. Nevertheless, allowing the user to make the changes in the first place-wastes the users time; and, it can be very frusrating.

The solution to this concurrency problem is to lock the records before allowing the user to edit them. When the user clicks the Edit button, the program can lock the specific record in the parent table. When the second user clicks the Edit button, the program tries to lock the record, but finds it already locked by another user user. The program tells the user that the record is locked, and the user can move on to something else. Typically, you either retry automatically after a certain period of time. This alternative is to notify the user that the access to the Edit feature is denied, and let him/her decide whether the command should be attempted again.

Unfortunately, different kinds of database provide different methods for locking records (i.e., optimistic, pessimistic). Some also provide little infromation about who is locking a record, and why. One way to solve this problem is to add a ReservedBy or a ReasonLocked field to the database table. When the progam wants to edit a record, it puts the user’s name or edit status (i.e., read-only, read/write, writing, saving) in this field. Later when another instance of the program wants to edit the same record, it notices that the ReservedBy field is not empty, and it tells its user that another user currently has that particular record reserved. When it finishes editng the record, the original instance of the program resets this field to Null to remove its reservation.

3. Can I use events to notify the various computers of activities on the server?
If you are using OOP, then I suggest that you encapsulate the database functionality. When you create the objects, make sure to include any desired events. Of course, when the object is instantitiated, it should be done with the events activated.

In Visual Basic you declare can declare an object With Events, i.e., Public WithEvents Text1 As TextBox. There is another mechanism know as event multicasting. This terms means that an object can raise events in all the client modules containing a WithEvents variable that points to that object.

In VB, an interesting approach is to declare an explicit object variable, let it point to a particular control, and use it to trap that control’s events. This multicasting mechanism ensures that the variable receives the event notification wherever it is declared. This means that you can move the variable to another module in the program or to another form, or class, or actually virtually anything—and still react to all the events raised by the control.

_______________

Tags: best, distributed, practices

Under Forum