The smallest RealWorld implementation

Five years ago, I wrote an essay titled SPAs are Just Harder, and Always Will Be. I showed why traditional, server-side web apps are easier to build and maintain than Single-Page Applications (SPAs). The EWL team has applied this concept and, with the help of our built-in user interface, we’ve just completed the smallest RealWorld example implementation to date.

EWL RealWorld is available on GitHub. The following two charts show how it compares to the combination of the React front end with the ASP.NET Core back end.

  .NET code measured by  NDepend , with generated code excluded.

.NET code measured by NDepend, with generated code excluded.

  React JavaScript/HTML code measured by  Jacek Schae  with  cloc . React CSS code measured from  Conduit template , which is provided by RealWorld but is something you would maintain if you owned the app.

React JavaScript/HTML code measured by Jacek Schae with cloc. React CSS code measured from Conduit template, which is provided by RealWorld but is something you would maintain if you owned the app.

What Makes the Difference?

The EWL implementation is not only smaller because of its traditional server-side architecture, but also because EWL includes a built-in user interface and automatic form layout much like what is provided by proprietary low-code platforms such as Salesforce and Mendix. There is no hand-coded HTML and very little CSS. As an EWL developer, you give up some control over your app’s look and feel in exchange for a big productivity boost.

Other Benefits

EWL RealWorld gets a lot for free:

It also runs on an open, cloud-agnostic operations platform.

Short-Term Weaknesses

We began the EWL project with the birth of .NET in 2002. Its web framework started as an extension of ASP.NET Web Forms, which is why EWL systems still include .aspx files and ugly, query-string-parameter URLs. We’re in the midst of a multi-year project to move the web framework to ASP.NET Core, which will fix these issues while also enabling all EWL systems to run on Linux. The bulk of our changes are taking place under the hood, which means you can begin an EWL project today and expect no more than the usual number of breaking changes each month (the home page explains our continuous-adaptive-maintenance approach).

Spring 2018 new web framework features

EWL’s web framework now includes some new, .NET-Core-compatible (i.e. without Web Forms dependencies) form controls: TextControl, EmailAddressControl, and TelephoneNumberControl. Similar to the new HTML editors and hidden-field component, these take most of their parameters via Setup objects to avoid duplicate parameters in (1) the form-item-getter methods that EWL generates for database columns and page query parameters, and (2) the new DataValue extension methods, which make it easier to create form controls for ephemeral data within a page, such as a search box. The new form controls follow accessibility best practices, for example by supporting proper labeling via the HTML label element and using correct input modes on mobile devices.

We’ve also reimplemented page “autofocus”, which lets you specify the location of keyboard focus when a page loads in the browser. The old implementation depended upon Web-Forms Control IDs, and had a couple of significant design problems that we observed over the years. First, to specify focus on a control, the page needed a reference to the control’s ID. This worked well for simple pages, but in complex pages with many nested components, it took a lot of ceremony to get a control reference all the way up the call stack to the page level. Second, the only way to override the focused control after a post back was to specify the control’s ID before the post back. This is impossible if the control doesn't exist yet! Our new design is based on wrapper components, called autofocus regions, and fixes these flaws. Read more in the release notes.

 Autofocus regions

Autofocus regions

Recent EWL Improvements

EWL is constantly under development, with updates being pushed to the Canonical branch almost weekly. Here's some changes recently released.

Application-wide database caching

EWL supports almost-automatic database caching. When this feature is enabled (which is why it's not completly automatic), TableRetrieval queries use row versions to determine if up-to-date rows are already in the cache and if so, does not require pulling data from the database. This ia a major improvement to the existing automatic database caching which was per-request only. This feature is supported for both Oracle and Sql Server databases.

Excel exporting is now supported for free

Our previous implementation for creating Excel files required an Aspose license. We have since replaced the solution with a free solution based on Open XML, at the expense of dropping support for legacy Microsoft Office formats.

Automatic ETag generation for blob responses

When sending a file to the browser, the framework will automatically generate ETags headers. This of course provides the massive benefit of not re-transferring files which a client has already received, benefitting the client, the server and our bandwidth costs!

Now supporting charts

This feature is a little less-new but it still counts. EWL supports both bar and line charts while automatically displaying values in a table and allowing users to export the data into a tabular file. Drawing report pages has never been easier.

Follow @EwlTeam on Twitter to keep up with EWL updates!

My name is Sam and this is why I use EWL

Hello! I'm Sam and I'm a .NET web application developer. I have been contributing to Enterprise Web Library for about six years. I wanted to do our first post on why I use EWL.

I enjoy learning about all of the frameworks that I can, trying to figure out their positive and negative attributes. This includes frameworks that aren't even on the C#/.NET stack, such as PHP, Ruby and Python. I definitely try to keep an open mind.

That being said, EWL is still my first choice when I develop data management systems.

I honestly don't know of a faster way to create a powerful, usable interface for modifying the properties and relationships of entities in a database.

In one sitting I can create, from scratch, a web application that can perform all of the CRUD operations I need for a small to medium sized database. I'm talking about add/modify/delete rows for tables of string/numeric/date columns and their relationships. Inlcuding controls that make sense for the data type. I'm not typing date-strings that need to be parsable by .NET. I'm talking about datepickers and dropdowns you can type in to filter.

It's free

And MIT licensed.

Fast, non-magical data layer.

There are powerful data layers out there. But one problem I find with them is too much magic. What is it actually doing under the hood? Because sometimes that's important. Entity Framework uses this magic that allows you to use normal C# convert code and it converts it to SQL. That's awesome. What's not awesome is that sometimes at runtime you'll find out that some particular C# you tried to use does not translate to SQL. "There is no conversion for myString.ToUpper()". Mistakes like this aren't possible with EWL because it makes an effort to force errors to be found at compile-time.

Looks good enough

I don't need it to look like a work of art, I need it to look professional with minimal effort, but allow me to make the changes I need when I need to make them. EWL is not the framework I use to build a custom, gorgeous portfolio website that is provided to me with mockups from a designer. It's what I use for business applications and the administrative backend to my websites.

So there you have it! If you have time to explore EWL as a possible solution for your future projects, be sure to use the Wiki and the enterprise-web-library tag on if you get stuck.