This is a showcase review for our sponsors at The Code Project. These reviews are intended to provide you with information on products and services that we consider useful and of value to developers.
Iron Speed Designer Version 5.0 now Released: PDF report generation and Excel exporting features enhance database applications.
"Database Layer—all your SQL and transaction management: All the SQL queries for data display and reporting as well as record insertion, modification and deletion. Advanced features include multi-table joins and a page-based transaction model."
Table of Contents
|
|
 |
Developing Web 2.0 applications provides an opportunity to bring desktop functionality to the web by building highly-creative, user-friendly applications like these:
To most application users, Web 2.0 applications look better than traditional desktop applications, and they’re also perceived as much easier to use. Web 2.0 applications afford the opportunity to reach out to both internal and external users like never before, and many organizations are enhancing web applications to integrate customers and suppliers, in addition to internal users.
At the same time, building web applications put you, the developer, in a completely different paradigm. Web 2.0 applications add additional development burdens of security, stateless transaction management, page-based navigation, as well as a variety of user interface features, which you wouldn’t normally worry about in traditional desktop client-server applications. Even though platforms like the Microsoft .NET Framework deliver the basic OS-level services for these applications, you still must write SQL statements, create hundreds of web pages, and code your application’s business logic.
Smart IT departments are efficiently conquering many of these critical issues, and focusing resources on creating intellectual property that's truly unique to their businesses. They are using a new breed of software tools called application generators to eliminate hand-coding of the infrastructure programming. Application generation takes a giant leap forward, offering a broader, more comprehensive solution. Application generators such as Iron Speed Designer create a significant portion of your entire application for you, frequently as much as 80%-90% of the application.
Accelerating the development cycle without sacrificing performance, features and interoperability, are key benefits provided by application generation. This white paper describes how one application generator, Iron Speed Designer, works. It combines point-and-shoot application generation with Web 2.0 functionality, speeding development and reducing costs.
Why is application generation so important and useful for modern application development?
- Speed application development and deployment. Application generation saves weeks and months of development time by generating the routine infrastructure code, freeing you to focus on your business logic. Most application development projects start with a handful of page mock-ups – or white board sketches – and a database schema. Iron Speed Designer uses your database schema as input and generates your application’s infrastructure, including the transaction management code and SQL queries, in a fraction of the time of hand-coding.
- Reduce development costs. Creating applications in a fraction of the time means you can develop and deploy applications faster and more efficiently with less cost in human resources. Your clients will be amazed at how quickly you can build proof-of-concept systems, gather feedback, and deploy applications.
- Maximize your IT department productivity. Most developers dread building features such as paginated reports, hierarchical navigation, filtering, and full text search, because the amount of time required is not proportional to the challenge or interest they create. Application users expect them, but there’s usually quite a lot of coding involved. Iron Speed Designer frees your team to focus on the higher-level development aspects that support your specific business needs.
- Reduce mind-numbing work. Each page in a web application can contain five or ten separate SQL queries, each of which has to be written, debugged, and vetted for performance. However, by using application generation tools, you don't have to worry about manually programming web pages, controls, or SQL. The repetitive nature of data insertion, retrieval and display operations permit their use as repeatable templates, or code patterns, in an application generator.
There is no precise definition of a Web 2.0 application. For our purposes, we’ll describe them as applications that bring desktop application functionality to web applications for the purpose of providing rich transaction-centric user interfaces.
Corporate applications have moved to the Web, and with them the need for rich application interfaces, especially for data entry, workflow and reporting. The Web has evolved well beyond information display and order entry / shopping cart applications into the preferred environment for deploying complex corporate applications. Web 2.0 applications provide desktop-style interaction in a stateless Web environment, a challenging task at best.
How are these rich user interfaces implemented? Largely by using a set of new technologies such as Ajax (Asynchronous Java and XML) and ASPX for user interface development, and web services and ADO.NET for data source access.
 |
Ajax-enabled controls like pop-ups and rich text editors are examples of functionality frequently found in Web 2.0 applications.
|
What are some specific characteristics of Web 2.0 applications?
- Rich components are a hallmark, frequently ‘mashed up’ from a variety of sources to create a rich, comprehensive application. These components may be hosted on a variety of servers and sites, effecting a truly distributed application.
- Individual web page controls interact intensively with server-side code. Interactive search, calendar and scheduling controls, and increment and decrement buttons, all interact with server-side code in real-time to provide users with dynamically updated information.
- They don’t postback, or at least appear to postback. Postbacks refresh the page causing annoying flicker. Web 2.0 applications use Ajax and other techniquest to provide a ‘smooth panel update’ of the affected screen areas.
From a corporate application perspective, Web 2.0 applications provide rich interaction as Web 2.0 applications displace desktop applications for data entry and workflow use.
Most Web 2.0 applications are database-driven, meaning they are used for data input, data display and data manipulation. Most bespoke applications fall into these basic types:
- Data entry and management – applications that collect data from users and allow that data to be edited.
- Reporting and tracking – applications that report and summarize data.
- Workflow and scheduling – applications that implement basic step-wise business processes.
- Business process automation – applications that implement advanced business process, often orchestrating data flow between multiple systems.
 |
This Web 2.0 workflow application lets users process transactions from a single web page.
|
If these application types sound like client server applications from the 1980’s and 1990’s, you’re right. Modern Web 2.0 applications are those you would have built using a combination of desktop applications for rich user interaction coupled with a back-end server for centralized data storage and processing. Fortunately these Web 2.0 application types are ideally suited to an application generation approach.
Imagine creating 80% to 90% of your application just by pointing a wizard at the database(s) underlying your application-to-be? All of the Web pages and components – tables, panels, and controls – are magically hooked up with each other and the underlying databases, and all the associated code is generated for you. That’s exactly what Iron Speed Designer does, illustrating the power of application generation. Iron Speed Designer’s approach to application generation is very straightforward:
- Start with your application-specific data model – an existing database or other data asset.
- Automatically create a set of fully functional application web pages for common database operations, such as adding, editing and viewing data.
- Automatically create a set of fully functional application web pages for reporting and workflow.
- Generate everything needed for a functional n-tier application – all the web pages, source code and SQL queries – and deliver a working, bug-free application.
- Automatically generate “pure” source code in native .NET languages, such as C# and Visual Basic, without any proprietary run-time servers or libraries.
- Generate built-in application security.
- Generate complete and well organized source code that's easy to modify and extend. Allow handmade code customizations to the generated application, automatically preserving them during subsequent application regenerations.
Application generation recognizes that only a small percentage of the code in any application is the “secret sauce” – the truly unique elements of business logic that differentiate one application from another. The vast majority of most web applications consist of fairly standard components – tables, panels, and controls – that lend themselves to being automatically generated and connected by an application generator. Only the unique application logic remains to be written by hand.
A brief example illustrates this point. Suppose you need to build an order entry system that allows sales people to create, edit and retrieve sales orders. This application might have an input form for adding and editing orders and a table page for displaying orders for any given customer. Using an application generator, the developer selects various database tables and views and the appropriate mapping between the underlying database and web page components. When ready, the developer lets the application generator produce the underlying application web pages, source code and SQL, including code for all of the web pages, controls, and database connectivity infrastructure.
 |
|
The Application Wizard in Iron Speed Designer generates sophisticated Web 2.0 pages from selected database tables and views.
|
Database-driven applications like these lend themselves to application generation because they use typical database connectivity and application infrastructure. They all need data entry pages for the selected database tables and views, reporting pages to view and analyze the data in the application, application security, and other application infrastructure.
Data is either being entered into a web form and inserted into the database or data is being retrieved from the database and displayed on a web page. These data operations are ideal for a templatized approach to application development, enabling an application generator to create the application and its infrastructure based on page and code templates using standardized and well-accepted ways to perform certain common operations.
Translating an end-users' vision into a functional and intelligent web application requires three main steps, each of them non-trivial.
- Design and create the hundreds of web pages required to access and run your application, including data entry forms and reports;
- Build the application's basic Web 2.0 functionality — sophisticated features ranging from filtering and sorting, to search and pagination;
- Connect web pages and their components to the database, implementing the underlying SQL and transaction management code.
Fortunately, Iron Speed Designer can help with each of these steps. Iron Speed Designer generates full-featured Web 2.0 applications for .NET in minutes, shaving months off the development cycle. Iron Speed Designer is different from other rapid development tools because it generates complex user interfaces and all the SQL and supporting code, without you having to design or code the pages or know SQL.
Using Iron Speed Designer, a custom, working application—not just a prototype or individual components—is quickly generated. The generated application’s architecture preserves your modifications and enhancements each time your application is regenerated.
Most Web 2.0 applications are built on an N-tier architecture comprised of:
- Web pages — the ASPX web pages comprising an application.
- Presentation Layer — the web-based user interface including database-connected forms, tables, and reports.
- Application or Business Layer — C# or Visual Basic .NET application functionality.
- Data Access Layer — SQL and transaction management code.
- Stored procedures — database server-resident SQL.
Implementing transaction-based Web 2.0 applications can be difficult because of the stateless nature of the web. Because web applications are stateless, they can require complex database management to implement complicated transactions, especially those spanning multiple web pages such as multi-page data input wizards. While a client-side browser can display pages, it can't be used to implement database transaction logic. As a result, the server-side application must coordinate and manage every aspect of these database transactions.
 |
Iron Speed Designer generates a complete N-tier application.
|
The next sections show how Iron Speed Designer generates each of these layers.
While designing an application's look-and-feel is not trivial, repeating it over and over for each of the hundreds of pages in your web application is a significant chore. Iron Speed Designer eliminates this struggle by automatically creating a suite of pages for each database table or database view in your application. These pages reflect the basic operations performed with any database table: Create record, Retrieve record, Update record and Delete record –sometimes referred to as C/R/U/D pages.
- Add Record – a page for inputting data for an individual table or multiple tables.
- Edit Record – a page for editing data in an individual record or query
- Show Record – a page for viewing data from one or more tables and queries.
- Show Table – a paginated, interactive report view of a table or query’s data.
- Edit Table – an editable data grid useful for editing a quantity of records.
The generated pages include corresponding application layer code, database transaction management code, and the underlying SQL queries and stored procedures. All of the generated pages are automatically linked together with a menu navigation structure, providing an out-of-the-box application with no additional coding required.
 |
These four standard database-connected web pages can be automatically generated for each table in your application.
|
Iron speed Designer goes beyond basic C/R/U/D pages, however, by creating a variety of Web 2.0 pages and features you would normally expect to find only in custom desktop applications, such as:
- Master-detail pages – pages for displaying, adding, and editing information from subsidiary “detail” tables referencing a “master” parent table, typically through foreign key relationships.
- Workflow pages – pages for displaying and processing workflow sequences that automate business processes.
- Reporting – pages that summarize data, including PDF and Microsoft Word reports that can be printed and emailed.
- Data integration – features that export data in a variety of formats for further analysis by application users.
 |
Master-Detail pages are among the advanced Web 2.0 features generated by Iron Speed Designer.
|
Web 2.0 features extend beyond page types to the components in those pages. These components might include rich text editors, tree controls, multi-level menus and tabbed panels for data input and display. Complex navigation especially defines Web 2.0 applications with features such as multi-step wizards for data collection and workflow processes governed by application user interaction.
 |
Web 2.0 components like this rich text editor generated by Iron Speed Designer bring desktop functionality to web applications.
|
Advanced application features like integrated security, reporting, multi-lingual support, and data integration are also hallmarks of Web 2.0 applications.
 |
Export formatted data directly to Microsoft Excel for further analysis and reporting. An Excel-readable XML file reduces the need to format data after import. Just click the Export to Excel button to view the data directly in Microsoft Excel.
|
When generating the application, Iron Speed Designer reads the page and code generation and generates corresponding .NET data-bound controls, server-side code-behind logic and transaction management code – ASPX, C# or Visual Basic and SQL – that is the bulk of the application. Iron Speed Designer automatically generates every SQL query and the wrapper code around it for each web-based component that accesses the database. Thus, you do not have to write any code to create sophisticated user interface-based applications with Iron Speed Designer.
Even for experienced developers, application scalability is hard to implement. Since all of the business logic in web applications is concentrated server-side in the application layer, scalability becomes a big issue for web applications. Functionality isn't distributed to the client-side as it is with client-server applications, so you can't rely on the application user's machine to offload computationally intensive tasks. Hence, improperly designed applications can cause performance bottlenecks in the middle-tier.
Iron Speed Designer builds applications with a three-tier architecture that scales easily, including optimized SQL, and advanced transaction, cache, and session management techniques.
There are likely dozens or even hundreds of pages in your application, each needing SQL queries to implement functionality plus wrapper code to glue it all together. Those pages include input forms, reports, and all sorts of pages where data is displayed in a variety of formats. Writing the SQL queries is often the most challenging task for web application developers, usually requiring the help of a DBA or SQL specialist. It's important to consider these application generation issues:
- Transaction management
- Location of the SQL statements
- SQL Efficiency
- Concurrency handling
- Cursor management
In web-based applications, it's particularly difficult to maintain state from one page to another because of the stateless nature of the web. This makes it important to understand what constitutes a transaction and when it should be committed to the database. For example, a typical web-based order check out process, such as a shopping cart, collects different aspects of the order in a series of pages, such as the customer’s name and address, credit card information, and shipping instructions.
The difficulty is that there are few options for storing information collected on those pages other than in the database, in the .NET cache or in browser cookies. Unfortunately, storing a user’s transaction information in browser cookies poses security and bandwidth issues. So, for most applications, storing transaction information in the database is the best option. This makes it important to understand what constitutes a transaction and when it is committed to the database.
Iron Speed Designer generates applications with a “page-based” transaction model. This means that all of the changes made to any underlying database table on the current web page are submitted when the user clicks “OK” (or takes a similar action on the page). I.e., upon clicking “OK” (or similar action), all changes made on the page are committed to the database as part of a single transaction. Specifically, Iron Speed Designer applications use the transaction classes in ADO.NET to perform commits and rollbacks.
 |
This order form illustrates how data can be called from multiple database tables into one page in a parent-child relationship. When “Save” is clicked, records are inserted into several tables, including the Order, Order Details, and Customer tables. In particular, multiple records are inserted into the Order Details table, one record for each line item. The entire transaction is concluded with a single commit.
|
Iron Speed Designer uses stored procedures to update the database when appropriate. If there are multiple related records being added or updated as part of a single transaction (e.g., Orders with multiple Order Items), then each record is updated individually requiring multiple round-trips to the database. The record insertions, updates, and deletions themselves are performed within database stored procedures, but the application logic calling these stored procedures is resident in the generated code.
In a multi-part transaction, the entire transaction is concluded with a single COMMIT statement at the end of the transaction. I.e., while these many-to-many updates do require multiple trips to the database, they are committed to the database by a single COMMIT at the end of the transaction.
SQL Location: In-line or Stored Procedures
Most DBA's prefer placing SQL in stored procedures because it centralizes all the queries in one place where they can be conveniently accessed and reviewed. Moreover, storing SQL in stored procedures can improve efficiency by pre-parsing the queries and reducing round trips to the database. Iron Speed Designer, for example, gives you the option of placing generated SQL statements in stored procedures instead of in line, in the application code itself.
Most developers use stored procedures to enhance run-time performance and minimize the number of round trips between the application program and the database. Getting information into and out of stored procedures must be done through a technology that interfaces with the database, such as ADO.NET.
Preserve Your DBA’s Sanity
Most IT departments have a database specialist who either writes all the SQL statements or helps individual developers write them. This approach ensures that all the SQL statements are written accurately and optimized.
Using application generation tools like Iron Speed Designer to generate your application’s SQL frees your DBA to focus on database management. Iron Speed Designer generates all the SQL needed for your application and places them in stored procedures so the DBA can find them as needed. Application generation removes the dependence your application developers have on DBAs and relieves your DBA from this often daunting task.
|
There are, of course, good reasons to place SQL queries directly in the database as well (e.g.: legacy applications and DBA preference). Because Iron Speed Designer generates all the SQL statements, developers don't have to learn proprietary stored procedure languages, such as PL/SQL (Oracle's stored procedure language) or Transact-SQL (Microsoft’s SQL Server language).
SQL statements are hard to write even if you are an expert. However, writing efficient SQL queries can have a genuine effect on the performance and scalability of your application. This is especially true in the state-less environment of the web, where maintaining transaction state between pages is difficult.
Iron Speed Designer approaches SQL generation from an efficiency perspective. For example, it places queries for multi-table joins in a single query to reduce round trips to the database. For optimal performance, it takes into account fields that are indexed. It even gives you the choice of placing your SQL directly in the application layer or in stored procedures.
Technology that generates SQL statements must be tied specifically to your database schema. Generic queries (queries composed on-the-fly that do not use parameterized field values) can slow down application performance since they often require several round trips to the database to complete. Specific queries that include the names of field values save trips because they use the actual field names from your database. This is how you would write the statements by hand.
In any multi-user environment, concurrency becomes an issue when two users update the same record in the database, one after the other. The way your application handles concurrency affects the ability of your application to handle simultaneous transactions against the same records.
 |
Concurrency handling ensures that application users don’t overwrite each others changes.
Concurrency handling is difficult to implement by hand but requires no development effort when it’s automatically generated.
|
In some applications, the second user to update a record will overwrite the changes made by the first. In others, the application will warn the second user that the record they are viewing has just been updated. In still others, the second user's view is automatically updated when the first user updates the record.
In traditional application development, the developer has to hand-code concurrency handling into the application layer. This can be tricky code to write, and it has to be written for each transaction in your application. Unfortunately doing it right doesn't earn you any special recognition whereas mistakes can have you hunting bugs for days.
Iron Speed Designer creates this concurrency management code for you, saving hours of hand-coding headaches. It generates optimistic concurrency handling code for each of your transactions so users cannot unintentionally overwrite each other's changes.
A database cursor is the resulting set of records returned by an SQL query. The cursor allows you to request each record in sequence so that the query results may be displayed in a data grid, report or otherwise operated upon. For example, as an application user moves from page to page in an on-screen report, the subsequent page's data is retrieved from the cursor and displayed. It's also commonplace for applications to iterate over the result set, performing some calculation or other update to each of the records in the result set.
 |
Cursor management ensures that only the requested data is pulled from the database into the application server, significantly reducing server-side processing demands.
|
Data recency. One issue that emerges with cursors is the freshness of the data in the result set. As long as the cursor is in use, it contains the set of records retrieved when the query was originally performed. However, this data may grow stale over time, especially if the query result is being displayed in a screen that an application user is reviewing over a period of time – minutes or hours. In applications where the underlying data changes frequently, it may be desirable to rerun the SQL query as the application user moves from page to page in their report. This ensures that each displayed page has the most current data. While this also places an extra load on the database because it must rerun the query more frequently, all modern relational databases have very good data cache management that significantly reduces the cost of frequently rerunning queries.
Data management. A second issue to consider is whether the entire result set is pulled from the database into the application layer, a well-known problem with .NET data grids. When a result set contains only a few hundred records, moving all of the data into the application program requires minimal bandwidth and memory to store and manipulate the result set in the application. However, when the result set has hundreds of thousands or millions of records, it becomes nearly impossible to efficiently move all of that data into the application program. Very few application programs are structured to manipulate that quantity of data in memory without additional file management logic, which defeats the purpose of using the underlying database which provides exactly these facilities. So, in applications where the result sets can be large, it's best to retrieve only a manageable subset of the result set from a cursor – such as one page of data – operate on that data, and then request the next subset.
Applications generated by Iron Speed Designer use database cursors to retrieve data from the database. The cursor is used to retrieve the number of records being displayed on the database table view web pages. Only one page of data is retrieved from the database and displayed at a time, minimizing the data transmission load and the application's memory storage requirements. Query results are not stored in a temporary database table view. They are retrieved directly from the database and displayed to the user.
Most applications serve a variety of constituents – customers, customer service, marketing, sales, and management, to name a few. It’s increasingly common in contemporary web applications to permit much broader access to applications and their underlying data than was common with client server applications, which had more restricted user bases. With broader use comes an increased need to partition data according to the user type – and sometimes down to the individual user as well.
Although most corporations take security precautions at the network level, the majority of application security must be built into the application code itself. Further, as much as we all wish it, the hackers and thieves will not disappear, especially when our networks connect to the public Internet and interface with outside customer and supplier systems. The bottom line is that a large part of your application security is in the program code itself. You can increase your application's security by taking advantage of the powerful benefits of application generation.
Iron Speed Designer generates applications with built-in features, such as:
- Role-based access control
- URL parameter encryption
- Automatic sign-out
- Data transmission encryption
Broadly speaking, Iron Speed Designer generates three types of role-based security:
- Simple sign-in authentication. Application users must sign into the application. Only users with user names and passwords can sign in, giving you control over who can access your application.
- Single-role authentication. Application users must have a designated role in order to access a particular web page. Individual web pages are configured so that only those users with the designated role can access the page.
- Multiple-role authentication. Individual web pages are configured to accept users who have one of several designated roles.
Simple sign-in authentication distinguishes between users who are signed in and those are not. Users who are not signed in are called anonymous users. Because of the flexibility in Iron Speed Designer’s role-based security model, you can grant access to individual pages to either signed in or anonymous users, or to both signed in and anonymous users. This is very useful when you want your application to present one view of your data to a signed in user and a different view, perhaps more limited, to users that haven’t signed in or don’t have an account (anonymous users).
 |
Automatically generating features like role-based security can save many hours of programming.
|
In more sophisticated role-based security systems, users can be assigned multiple roles, effectively giving them broader access than would be granted by a single role. A simple example is that every customer service representative may not be authorized to access customer credit card data. In this example, the customer service supervisor has one role as a "rep" with access to customer account information, and a second role as "manager" with authorization to issue refunds or credits. Ideally, those roles are accessible simultaneously without requiring the user to log in under a second role.
With role-based security, you can:
- Define user names and passwords.
- Create and assign multiple user roles for your users.
- Configure each web page for access by designated user roles.
- Generate your application’s entire role-based security infrastructure.
Applications generated with Iron Speed Designer utilize the highest level of security features offered in the .NET Framework and include built in security. Additionally, you can easily add features such as Windows authentication and Active Directory single sign-on. And, applications generated by Iron Speed Designer work well with existing network firewalls.
Parameters passed from page to page via URL’s can be encrypted so that hackers cannot decode record IDs, enabling them to access records via the URL they shouldn’t access. When enabled in Iron Speed Designer, the URLs for Show Record and Edit Record pages are encrypted using the Session ID as the encryption key. In some cases, the URLs for Add Record pages are also encrypted, such as when copying a record.
It’s virtually impossible to generate applications that require no code customizations– extensions made by hand to the generated application to add custom application logic, integrate with third-party components, and interface with external systems. While many administrative and data management applications can escape the need for customization, most generated production applications have some amount of hand-coding.
 |
Application generation encourages an iterative development style.
|
The application generation process must produce code that is readable, easy-to-understand and easy-to-modify; otherwise the time benefits achieved by application generation are for naught. There are perhaps two principal concerns in using an application generator:
- Understanding how to customize the generated application. An application generator generates code in a certain code model. Customizing that generated code relies on your ability to understand that code model.
- Preserving each time the application is regenerated. The great thing about application generators is their ability to quickly regenerate an application using different data sources and developer preferences. That regeneration process must preserve any code customizations you’ve made so you don’t lose any work.
Both of these concerns are addressed in the following sections.
How physically attractive are these automatically created web pages? Iron Speed Designer uses a template-driven approach to generate web pages. Over 25 different design themes are included with the product, providing a variety of layouts, color schemes, and other important visual attributes. In short, generated applications look great without any customization. More importantly, these design themes can be customized, allowing developers to either modify one of the design themes to their liking or create one of their own.
 |
Style sheets control nearly every stylistic element in applications generated by Iron Speed Designer. This makes look-and-feel customization very straightforward.
|
Design themes are comprised of several important components:
- A style sheet (.CSS cascading style sheet) defining the basic stylistic aspects of a design theme, such as the fonts, colors, and table styles.
- A set of pages and panels containing HTML and code generation tags that encapsulate useful functionality, such as a set of record fields or a table display.
- Images for buttons, thumbnails, and other purely graphic elements used in the design theme.
Nearly all look-and-feel aspects can be controlled by changing the appropriate CSS class, making it easy for non-developers and graphic designers, to modify the stylistic elements of the generated application.
It’s fairly common to modify the layout of controls on generated application pages to achieve a tighter or more logical layout than can be guessed by the application generator. The ASPX web pages generated by Iron Speed Designer are CSS 2.0 and XHTML 1.0 compliant, so modifying them is a straightforward process of opening the appropriate file in your favorite web page editor, such as Dreamweaver, Microsoft Visual Studio, Microsoft Front Page or in Iron Speed Designer itself.
Using your favorite programming language including C# and Visual Basic, you can extend your generated application to:
- Add custom application logic
- Add additional user interface code
- Integrate with external systems
The class hierarchies generated by Iron Speed Designer derive from the base classes in the .NET Framework. In most applications written for the Microsoft .NET Framework, the functionality and logic in the Application Layer are derived from a set of C# or Visual Basic .NET classes that implement page management, user interface controls, database access, and data validation.
This object inheritance code model allows you to intercept Windows messages going to a form or control by sub-classing the appropriate class and method, among other benefits. Using your favorite code editor, such as Microsoft Visual Studio or the code editor in Iron Speed Designer itself, simply subclass the appropriate page, control or database class and add your code customization.
 |
|
The inheritance hierarchy for a typical web page generated by Iron Speed Designer.
|
You can override any of the functions or methods in the generated classes or the .NET Framework classes, or write your own methods in combination with the existing base class methods. Then, regenerate the application to reflect your changes.
Iron Speed Designer generates native .NET code, including ASPX pages, ASCX controls, SQL statements, C# and Visual Basic code. Developers enjoy unrestricted access to 100% of the generated code and any modifications to the application are automatically preserved when the application is regenerated. There are no run-time license fees or special server software requirements for applications built with Iron Speed Designer.
One of the biggest challenges of application generation is code orphaning. Code orphaning occurs when your application cannot be modified or extended without severing the application generator’s ability to regenerate that application without losing your code customizations. Application generation encourages iterative development practices, but that’s impossible if customizing your application removes your ability to regenerate it.
Iron Speed Designer allows your application to be regenerated repeatedly without requiring you to re-integrate your external code extensions. This is accomplished using the object inheritance model so that the inherited classes you create for your code customizations are never overwritten when the application is regenerated.
The class hierarchy means your code customizations have access to the full functionality of the generated application, all the way down to the .NET framework. Only the generated classes – the automatically generated portions of your application – are ever regenerated; your inherited classes and methods are never regenerated, preserving your code customizations.
As long as your modifications are segregated in the sub-classed methods and not in the code, your application can be regenerated repeatedly without re-integrating your code extensions. Your code extensions are not overwritten when the application is regenerated, allowing you a high degree of flexibility in making code extensions to the application.
Iron Speed Designer’s Application Wizard generates the basic application using a set of page templates and code templates. The page templates contain the underlying HTML / ASPX for each page plus the conditional code generation logic that directs Iron Speed Designer to generate specific application and page features based on developer preferences and inputs. The code templates contain the C# or Visual Basic .NET code plus the conditional code generation logic that directs Iron Speed Designer to generate specific application features based on developer inputs.
 |
Iron Speed Designer uses page and code templates to generate applications.
|
As with the more basic page types and features, advanced page types and Web 2.0 features are implemented as a set of page and code generation templates that Iron Speed Designer uses to generate the application.
Because page and code generation is template-based, application developers can change the page content and underlying code that is generated for each application to include specialized features that might be commonly used within an organization. These custom features might include custom or third-party user interface controls, specialized security or access control, and custom data source access logic.
Page generation templates are snippets of HTML that can be as simple as one tag or as complex as an entire page. They contain the code generation instructions to generate data-bound controls at specific locations in the web pages. Because developers can modify these page generation templates, they can add their own pages and panels to Iron Speed Designer.
While adding new page types is beyond the scope of this white paper, suffice it to say this provides an extremely powerful capability to sophisticated developers.
