OpenEdge to Visual Studio .NET – Head to Head ComparisonLocked
One of my developers who has deep knowledge of Visual Basic .NET and experience with C++ and other languages was recently tasked with learning Progress OpenEdge. Being very frustrated by Progress developers telling me ?why? .NET is inferior and .NET developers telling me ?why? Progress was inferior without having much knowledge of the other or comparing it based on what it ?used? to be five or more years ago, I had him put together an objective comparison. It?s important to understand that up to this point all of my developer?s knowledge of Progress is book-based and not based on experience. He is now going to begin applying that knowledge and working on a sizable project with other Progress developers. At the conclusion of this project I?m going to have him update this information so that it?s experience vs. experience as objectively as possible. Since I can?t find a ?reliable? source of this information from anywhere else I thought I would share.
I would love to hear some comments regarding this from both .NET developers as well as OpenEdge developers! Here you go:
Topic: Development Philosophy
Advantage: Subject to Need
Description: Visual Studio .NET is a very powerful programming language. There is no limit to the variety of different applications that can be produced. With it you can produce data entry/manipulation/reporting applications, games, device drivers, etc. OpenEdge, on the other hand, is not interested in participating in certain segments of the development community such as game and device driver development. OpenEdge?s entire emphasis is in the area of data entry, manipulation, and reporting. OpenEdge is extremely data centric. To OpenEdge data is king. To say the database is the foundation by which an OpenEdge application is built upon is doing it a disservice. Instead the database is the core by which the OpenEdge application is built around much like the layers of an onion. With Visual Studio .NET development begins and ends with the code with the database being almost an afterthought. This is in contrast to OpenEdge code which acts as an extension of the database. The best way to describe OpenEdge code is to say that it is like Transact-SQL with a massive amount of additional functionality to control all aspects of retrieval, display, manipulation, storage, etc. This makes presentation an extension of the retrieval code making for a very quick development environment.
Below is a visual comparison of the two development philosophies:
Visual Studio .NET Development Philosophy (I couldn’t find out how to attach this. You can view the attachments on this blog entry if you wish: http://briandrab.spaces.live.com/blog/cns!B69C8C4D664E3F01!202.entry)
OpenEdge Development Philosophy (I couldn’t find out how to attach this. You can view the attachments on this blog entry if you wish: http://briandrab.spaces.live.com/blog/cns!B69C8C4D664E3F01!202.entry)
Topic: Runtime Interpretation
Description: Both OpenEdge and Visual Studio .NET applications compile to an intermediate language that is interpreted at runtime. With OpenEdge the Progress ABL Virtual Machine or AVM interprets the code at runtime. With Visual Studio .NET the .NET Common Language Runtime or CLR is used. OpenEdge applications have an advantage over .NET apps because while Visual Studio apps compile down to a single .EXE or .DLL file, OpenEdge apps compile to multiple, procedure-based files. This allows for greater flexibility with respect to testing and maintainability (See topics ?Testing? and ?Maintainability? for further details). The only caveat is that OpenEdge requires that the files be located within one of the directories identified by the ProPath environment variable. This is understandable when you consider that even Visual Studio .NET has a methodology for locating referenced assemblies. In many cases, however, those assemblies must be registered with the OS in order to be locatable.
Topic: Deployment; Flexibility
Description: Being interpreted languages both OpenEdge and Visual Studio .NET provide a high level of flexibility when deploying applications. As long as the operating system (regardless of which operating system that is) has the necessary runtime environment installed the application will work correctly. OpenEdge applications can take this flexibility one step further. As long as the application uses basic components it can run either as a graphical or character based interface. The AVM can make the determination at runtime as to the type of interface the application must run in. With Visual Studio .NET the type of application (GUI vs. Console based) must be determined during project creation and it is very difficult to change it after the fact.
Description: OpenEdge applications are deployed as multiple, procedure-based files while Visual Studio .NET apps are deployed as combined assemblies (See topic ?Runtime Interpretation?). The OpenEdge production environment matches that of its development environment. For example, consider an OpenEdge application that has a main menu containing two buttons. One button launches a data entry form and the other button launches a report. In our example the OpenEdge development environment consists of three procedure files that make up the application (MainMenu.p, Entry.p, and Report.p). When deployed the production environment will contain these same three files but in their compiled format (MainMenu.r, Entry.r, and Report.r). Within the production environment the ?.p? files and the ?.r? files can be used interchangeably. To clarify that point let?s assume that changes are made to the Entry.p form. Once the developer has tested and is confident in the changes he can move the ?.p? file to production and temporarily rename the ?.r? file to test how the change will work against the production data. This can also be done while users are currently in the production application. This cannot be done in Visual Studio without recompiling the entire assembly and kicking users out of the production app.
Topic: Development; Events
Description: Being event-driven languages both OpenEdge and Visual Studio .NET control program flow based on application events. With Visual Studio .NET the process involves establishing interest in receiving events from the source object (i.e. ?WithEvents?) and then creating code to handle the particular events of interest. With OpenEdge ?trigger? code is created to handle events thrown back from the object. It is not necessary to establish listening capability. OpenEdge also takes event handling to the next level by providing a means where procedures can publish or subscribe to events. With Visual Studio .NET you can only handle events raised from objects you have an instantiation to. With OpenEdge you can establish publications within a procedure then, in other procedures, establish a subscription to that publication. When the publisher throws the event the subscriber executes its internal code. You can have multiple subscribers to a published event. Another nice feature which is related in a way is that OpenEdge provides a function that returns a reference to the procedure that called the current procedure. No other programming language I?m aware of provides this information. You can then use this reference to execute procedures contained within the source procedure. If the source procedure does not contain the particular procedure called upon any error that would result will be ignored provided the developer included the ?NO-ERROR? keyword when executing the call.
Topic: Development; Presentation
Description: As mentioned earlier, presentation within an OpenEdge application is really just an extension of the code used to retrieve the data. With OpenEdge, presentation begins with the data field. The developer can control all aspects of the field?s presentation including the type of control to use when displaying the field. This is done with the ?VIEW-AS? keyword however this merely overrides the value, if any, that can be set as the default within the field?s definition at the database level. With Visual Studio .NET, presentation begins with the control. The developer controls all aspects of the control?s presentation. More code then becomes necessary to either bind the control to a data object or manually manipulate the control?s contents. Fields within OpenEdge applications keep separate buffers for their data; one for the record buffer and one for the screen buffer. The record buffer is the interface to the actual value stored in the database table for that field. The screen buffer is the value displayed to the user on the screen. The advantage of this is that changes made to the screen are not committed until the field’s screen buffer is assigned to the record buffer. Undoing a change is simply a matter of having OpenEdge reassign the record buffer to the screen buffer.
Topic: Development; Parameters
Advantage: Visual Studio .NET
Description: In Visual Studio .NET, when passing parameters, you have limited choices. In VB you can choose to pass parameters ?By Value? or ?By Reference?. It?s basically the difference between passing the entire object to the called procedure where a copy is made or simply passing a pointer to the original object in which the object is shared. Of course you have to have an understanding of exceptions. For instance, all objects passed to a procedure running in another process are passed by value regardless of how they are declared. OpenEdge, on the other hand, has a slew of choices when it comes to passing parameters. So much so that it pains me to even think about trying to give examples here. In my opinion this makes the process of trying to determine the best way to pass a parameter far more complicated than it needs to be. This is an area where there is a rather large learning curve.
Topic: Development; IO Operations
Description: It?s been mentioned before that OpenEdge is tightly integrated with the data (See topic ?Development Philosophy?). The methods used to display information on the screen, import/export it to a file, send it to a printer, or receive/transmit it to a device are exactly the same. The main difference is a single line of code used to identify to OpenEdge the source/target. Obviously this same functionality is available in Visual Studio .NET but is much more of an involved process.
Topic: Development; Transactions
Description: Under most circumstances OpenEdge will inherently use transactions when updating the database. This is primarily a result of the code being so tightly integrated with the data (See topic ?Development Philosophy?). Transactions generally start automatically during iterations through a table (i.e. ?DO? or ?FOR? loop) but are not limited to iterations alone. With Visual Studio .NET you must explicitly indicate when you wish to start, commit, or rollback a transaction. Even though OpenEdge handles the transaction by default it is still recommended that you explicitly designate where a transaction begins or ends to better control the duration in which records are locked. By default variables declared within OpenEdge are subject to transaction rules similar to any database fields within the same procedure. This means that if a transaction is rolled back all variables that were changed since the transaction was started are rolled back as well. When declaring the variable you have to specify the ?NO-UNDO? keyword to disable this.
Topic: Development; Batch Access
Description: Similar to transaction functionality (See topic ?Development; Transactions?) OpenEdge provides built-in functionality for batching data. With it OpenEdge can be configured to pull down data in chunks. The initial batch of data is retrieved when the user first makes a request. As the user navigates the data OpenEdge will transparently and seamlessly retrieve successive batches of data from the server. This greatly relieves network traffic. Out of the box Visual Studio .NET does not provide this type of functionality. In addition to batch retrieval the developer can control when individual fields are returned. For example, a form is created to display customer information. The developer defines a ProDataSet which contains all of the customer fields to display to the user. Initially, when the form is loaded, the code only populates the CustomerID and CustomerName for every customer record. A selection combo box gets its information from the ProDataSet, more specifically from the CustomerName field. Once a user selects a customer from the combo box the code populates the remaining fields in the ProDataSet for that customer alone. Again this greatly relieves network traffic because the application only retrieves the information it needs when it needs it. This functionality is not easily reproducible in Visual Studio .NET.
Topic: Development; ActiveX
Advantage: Visual Studio .NET
Description: Although OpenEdge can utilize ActiveX objects and controls to do so is an overly complex process. For example, internally ActiveX controls have, at their top most level, a container which encapsulates the control. When an ActiveX control is placed on an OpenEdge form a special OpenEdge container is created to encapsulate the control. On its surface you would think this is unnecessary but the truly unnecessary part is that this container actually holds another, special OpenEdge container. It?s that container that actually holds the ActiveX control. You can imagine the kinds of hoops one must jump through in order to access the control?s properties and methods. In my opinion Progress has over-thought this. Similar to the topics discussed in the topic ?Development; Parameters? this is an area with a rather large learning curve.
Topic: Development; Memory Leaks
Description: In most programming languages (Visual Studio .NET included) ensuring that you?ve cleaned up objects you?ve created is an important facet of the process otherwise memory leaks will steal valued resources and, eventually, will crash your system. Visual Studio .NET made great strides in this area with the inclusion of a Garbage Collector to seek out abandoned objects and reclaim vital memory. However, situations remain where objects can be created but then fall off the Garbage Collector?s radar. OpenEdge provides special object pools that, once created, automatically keep track of all objects sent to them. If a form is created with OpenEdge?s AppBuilder interface a pool is created that automatically tracks all the objects created within the form. Developers have the option of manually creating pools for special purposes and assigning objects to them. This is not a requirement because if an object is not specifically assigned to a pool OpenEdge will move up the call stack until it finds a pool and will make the assignment. When a pool loses scope all objects contained in the pool are automatically destroyed and their resources reclaimed. An OpenEdge application leaves no resources unclaimed because at its top-most level is a session pool that is automatically created on session start. In addition, OpenEdge includes a ?Dynamic Object Tracking? dialog box which allows the developer to monitor the creation and destruction of dynamic objects. In that way a developer could set breakpoints at strategic areas to identify if there are places where objects could manually be destroyed to improve performance.
Topic: Development; Performance Tweaking
Description: OpenEdge has built-in logging functionality providing vast quantities of information at varying levels of detail. The feature is off by default but can be enabled in both the development or production environment. With it all aspects of an application?s operation can be captured to identify problem areas or areas that could be improved upon. The OpenEdge manual ?Debugging and Troubleshooting? dedicates two entire chapters to logging. Visual Studio .NET has logging capability which is pathetic by comparison.
Description: Both OpenEdge and Visual Studio .NET allow the developer to debug running applications on both local and remote systems. The difference is that, with Visual Studio .NET, target applications must be compiled as special ?Debug? versions. With OpenEdge you can connect to and debug the production application unbeknownst to the users.
Topic: Deployment; Scalability
Description: In addition, it was mentioned that individual procedure files are located at runtime as long as they are within one of the directories identified by the ProPath environment variable (See topic ?Runtime Interpretation?). As the application grows individual procedure files can be relocated to faster drives or, more importantly, application servers. With Visual Studio .NET whole assemblies must be relocated and, unless a technology such as COM+ is utilized, cannot be used by the presentation layer unless refactored.
Topic: Deployment; Interoperability
Advantage: Visual Studio .NET
Description: Although OpenEdge can interface with third-party DLLs and utilize their functionality it cannot provide the same functionality to other third-party applications in the same fashion. Third-party applications must utilize other methods to connect to an OpenEdge library through a Socket, Named Pipe, WebService, etc. Although it is still an interpreted language, Visual Studio .NET can compile to a library assembly with a ?.dll? extension. Windows identifies the file as a .NET library and reroutes the request through the CLR. I mentioned OpenEdge can interface with third-party DLLs although doing so harkens back to the days of VB6 interfacing with API functions. Each DLL procedure to be used must be defined and its parameters must be configured precisely in order for the call to work. Luckily, like VB6, OpenEdge provides a tool to help create the definition for you. Lastly, overall it is much easier in Visual Studio .NET to package data for transmission to other running processes. In the end OpenEdge has the capability to do all that would be required but, by comparison, it is much more involved (See topic ?DataSets? for additional information).
Topic: Maintainability; Mod Deployment
Description: As mentioned previously OpenEdge applications compile down to multiple, procedure-based files while Visual Studio .NET applications compile to combined assemblies. This means that when deploying a change to a Visual Studio application, regardless of how minor the change is, you must recompile the entire assembly and overwrite the file in production. With OpenEdge you only need to compile the specific procedure files that have change and only those files need to overwrite their equivalents in production. Also, as was mentioned in the ?Testing? topic, you can deploy the source version of the file (i.e. the ?.p? file). In effect, this would be equivalent to a pre-deployment to ensure the changes work without issue in the production environment. When you are confident the changes work as expected you can simply compile the procedure and place the ?.r? into the production location. OpenEdge automatically uses the ?.r? file if it is present even if the ?.p? file may still be in the same directory. The deployments of updated files can be done while users are currently in the application although, for safety reasons, it is advisable to get everyone out first.
Topic: Maintainability; Schema Changes
Description: OpenEdge variables can be declared to be ?LIKE? a database field they are intended to hold. Visual Studio .NET does not offer this functionality. For example, consider a procedure that retrieves the value of a database field and stores it in a variable for later use. At the time the procedure was written the field was defined as an Integer. Sometime after the application is deployed the field is redefined as a Long. In Visual Studio .NET the application will continue to work until that day when the number stored in the database happens to exceed the limitation for an Integer. With OpenEdge, however, you can set the variable to be ?LIKE? the database field during the variable?s declaration. In that way, when the field changes, the application will declare the variable to be the correct type at runtime. This is not limited by the data type of the field meaning that an Integer field could be changed to a Character and later changed to be a Decimal. As long as the change does not invalidate the code (i.e. calculation being done on an Integer field that later changes to a Character field) OpenEdge will not complain. In addition, variables declared with the ?LIKE? keyword not only inherit the data type of the source field but also, attributes such as format, label, initial value, help text, etc. Of course, any of the attributes can be overridden at the procedural level.
Topic: Maintainability; Monitoring
Description: OpenEdge provides an ?INDEX-INFORMATION? attribute which, according to the documentation, ?allows you to retrieve information about the indexes the AVM uses to retrieve the records that satisfy the selection criteria. If the AVM is able to use one or more index brackets to satisfy the query so that it does not have to read all the records in a table, the method returns a comma-separated list of the indexes used. You can use the INDEX-INFORMATION method to warn users of potentially inefficient queries or prevent them from executing queries that can?t use an index.? This is powerful functionality that Visual Studio .NET does not provide. With it developers could have the application create log entries indicating when the creation of new indexes could benefit the performance of the application or how often particular indexes are used and which ones could be removed. OpenEdge has a performance profiling tool called Profiler that can show you exactly how much of your processing time is going to what routines. Alternatively you can test the speed of a specific part of your code using a built-in function called ETIME (stands for elapsed time). ETIME returns an integer value representing the number of milliseconds since the function was reset to zero. Visual Studio .NET does not provide a tool to profile an application. Visual Studio .NET developers can gather the same information as the ETIME function but must do so manually.
Topic: Database; Data Types
Description: Visual Studio .NET, like most applications, expect character data fields to be no larger than a specific length. OpenEdge is flexible in that it does not have such a limitation. When you create a character field you are not limited by the amount of data you add to the field. The parameter that comes closest to such a limitation is the ?Format? parameter which represents how the field is to be displayed but even this is a default value that can be overridden. For instance, a Format of ?x(30)? means that, when displayed, only the first 30 characters should be shown. Of course this does add a level of complexity when querying the table from third-party applications via SQL. A separate property is provided in the field?s schema definition to communicate to the SQL driver the length of the field. If the data is permitted to exceed this length, however, unknown problems will ensue. I believe this is the primary cause to why we have problems sometimes querying certain fields from SQL Server. In addition, OpenEdge provides another nice feature which is virtually unheard of in other database management systems. With OpenEdge you can configure a field as an array. For example, you could create a field called “MonthlySales” as a Decimal array holding 12 values representing the 12 months in the year. In code you could access July?s sales figure as MonthlySales.
Topic: Database; Auditing
Description: OpenEdge provides core support for complete auditing of database activity from schema changes to data changes. The type and level of detail are completely customizable. Visual Studio .NET, or more specifically SQL Server, does not provide this functionality. Developers must manually create the functionality if auditing is required.
Advantage: Visual Studio .NET
Description: OpenEdge contains a class similar to a Visual Studio .NET DataSet called a ProDataSet. The documentation claims that a ProDataSet can be converted to or from a Visual Studio DataSet allowing the two technologies the ability to pass information between each other. While this may be true a ProDataSet does not contain all the properties and methods of a Visual Studio .NET DataSet. This means that in OpenEdge you must recreate much of this functionality manually.