A Smarter Way to Do Asynchronous Programming

The cover of MSDN Magazine this month carries the main headline: “Asynchronous programming.” Inside you will find three articles about these new proposed features that will make it easier to write code that will help to create efficiencies in Visual Studio applications for asynchronous programming.

The entire article is about how it will be possible in the future to write code that does what the Magic application platform has been doing automatically for its programmers for more than 10 years. Visual Basic and C# don’t have these capabilities yet, but they will in the future the articles proclaim, but it will still require the developer to add special code and the creators of these languages are so far away from a solution that they are using the magazine to solicit feedback on the idea. Wow.

I think it is easy for those of us familiar with uniPaaS seamless efficiency through multithreaded concurrent architecture to forget that other developers must tell their programs how to handle concurrency of task execution. I remember being very impressed with the initial analogy used to explain the Magic engine and the Magic broker: the example used was that of a restaurant with many waiters and a short order cook or cooks who were working on many meals in parallel, breaking down the meal preparation into discrete steps and jumping back and forth between tasks. 

At Magic Software, we talk a lot about how our advantage is a metadata driven architecture, but when you read the articles in this month’s MSDN Magazine it crystallizes some of the low-level nonsense that other developers put up with every single day without realizing that it Is a complete waste of time for them to be creating business applications in those languages (and don’t get me wrong, Java is no better). The sad thing for these developers is that they have to add lots of instructions to their code to tell the program how to process tasks concurrently. Really, in 2011 programmer drones are paid six figure salaries and still writing the same code concepts over and over again? 

Thankfully, there is a smarter way to do asynchronous programming and achieve highly efficient applications without giving it a second thought. That approach is found in Magic Software’s uniPaaS application platform. Even after Microsoft finishes its "enhancements" to C# and Visual Basic (tough luck if you're using a different Microsoft language) you will still have to manually add "await" instructions to your code. And since there was no thought put into forward-migration and everyone handled concurrency differently, you will have to manually strip out all the old concurrency code. Yuck! The three articles were nice, very enlightening as to the tedium on the other side of the fence, but as for me: here’s three cheers for uniPaaS!

To see a sample business application running in Magic Software's uniPaaS application platform see the RIA demo here. To read more about Magic Software's smarter application platform, see the information on the company website.

One-To-Many Programming: From the Cloud to the Ground

A Programmer’s View of One-to-Many

Let’s return to what David Remsen says about one-to-many data relationships: “When deciding upon how to best split data into tables we often ask "What are the logical units of the data?" In other words, what is best represented by a single row of data. It is often convenient to think of physical representations when applicable. For example, what types of information can we associate with a patient that only appears once. A person usually has one name and social security number so these can be safely placed in a table. We might add date of birth. [On the other hand] a person can have many tests. They might only have one but they might also have fifty. Thus one person might have many tests and this is represented by a One-To-Many relationship…”

As we stated previously, a one-to-many data relationship exists when one record from one data source is related to several records from another data source; a single country in a Country data source will be linked to many entries within a City data source. This much is clear and well known to developers and users alike.

With the uniPaaS application platform, development of an application that utilizes data that is in a one-to-many relationship is implemented by the interrelationship of two tasks or programs. In uniPaaS, a program is not an all encompassing application, but rather a very small but discrete task. Most developers in uniPaaS lean towards fine-grained programs because of their reusability.

The logic is very straightforward. The first task or parent task deals with the main record and the second task (sometimes call a child or subtask) deals with the "many" or multiple records that are related to the main record. This relationship is often displayed to the end-user using two different display formats, the parent program displaying the single record in screen mode and the child program displaying the multiple records in a table. This is not always the case, since you may decide that the parent program will also be a table.

uniPaaS uses a Subform control to display the child task's form within the parent task's form and refreshes the subtask each time the common variable is changed in the parent task.

A one-to-many data relationship is established between a primary data source and a secondary data source in such a way that each record in the primary data source has several related records in the secondary data source.

In a one-to-many relationship, there is a primary data source (the one) and a secondary data source (the many). The primary data source must contain a unique identifier or index to which the secondary data source can associate. The secondary data source will contain both the unique identifier of the primary data source (the reference index) and its own unique identifier (the secondary index).
This can best be illustrated through an example such as order numbers and order lines in an order entry program.

Primary Data Source

In the following example, the Orders data source is the primary data source.

An order record usually contains basic details regarding the order, for example:

Order Number

Order Date

Customer Code

Total Amount

Method of Payment

The Order Number will be the Unique index of the data source, since each record has a unique order number.

Secondary Data Source

The Order Lines data source is the secondary data source. It contains several data items:

Order Number

Order Line

Product

Quantity

Price

The Order Number and the Order Line will be the Unique index of the data source. The same order number can repeat several times with different order line numbers. The linkage between the Orders data source and the Order Lines data source is the Order Number.

For each record in the Orders data source there are several records in the Order Lines data source. This is the exact definition of a one-to-many data relationship.

Without the use of one-to-many data sources, all information would need to be contained in one record. This will cause problems, such as the end-user having to repeatedly type the same information, and large records because of the repeated data.
The result would be a large data source, which takes up more disk space and slows down the program's performance.

The solution to this problem is to define two data sources according to the following rules:

All of the repeating data columns should be defined in the primary data source.

All of the unique data columns should be defined in the secondary data source.

Both data sources should be connected using a common column.

The common column is the only column that will be repeated in the secondary data source.

Separating data into two data sources like we did in the Orders and Order Lines example has several advantages.

The separation saves the end-user from having to type the same data several times and it also reduces the size of the records.

Step-by-step procedures on the creation of a program that utilizes one-to-many relationships are available in Module 18 of the Getting Started with uniPaaS course. For a description of what we mean by a one-to-many application platform, see our previous entry.