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 StackOverflow.com if you get stuck.