Allometry

Flash Builder and ASP.NET, Part 1

Its been about a six month drought of no work and I’ve been trying to keep myself busy by writing in house applications to manage inventory and project information.

I had a small project come across my plate that is golden for guys like me that like to try and figure out how to make stuff work.

In this scenario, I needed to accomplish a few things:

• Write an ASP.NET web app to supply information via a service using .NET 3.5, ADO.NET Entity Framework and a MSSQL database.
• Write an Adobe Air application to consume those services
• The data model to be diagrammed is nothing more than a two table setup with a 1:n relation.

That’s a pretty broad approach to a project, especially since it’s a proof of concept demonstration that will act as a template, if successful.

In part 1, I’ll describe the setup I used to create this demonstration. In subsequent parts, I’ll dive into specifics on the .NET platform and on the Flex platform.

The setup is simple: Visual Studio 2010, MSSQL 2008 Express, .NET 3.5.

We were limited to .NET 3.5, since the organization we’re building this application for hasn’t rolled out .NET 4 on any of its desktops or servers. This is pretty typical in my line of work and I’ve learned to let the frustration go.

The database is simple: a users table and an items table. A user has many items. A user is an email address and a name, and an item is a key and value.

The entity framework ORM in .NET 3.5 isn’t as mature as the version in 4 and it’s a bit of a pain in the ass at times. However, you can use LINQ with it and that’s a huge plus.

When you connect your project to your database, EF can go to work and generate it’s objects based on your table. From there, you can name the connection string and tell EF what namespace its objects will use. At this point, you’re pretty much ready to consume data via ADO.NET EF.

The way my Flex application will consume data is over a web service, and we’ll use WCF as our platform. It’s easy to write and understand and ASP.NET has no issues delivering data over SOAP 1.1 or 1.2. There are lessons learned in this, so stay tuned.

Flash Builder is really good at consuming data from many sources, especially via SOAP. ASP.NET will generate a WSDL for your Flex app to consume, however it has to be delivered via a SOAP 1.1 envelope, not 1.2. This is something you have to manually configure in the ASP.NET web.config file, or else you’ll be scratching your head for a while.

Once Flash Builder has consumed the WSDL, it will generate it’s local objects and write all the code to handle the calls between client and server, without issue.

In part 2, I’ll jump into describing the back end of this equation on how the ASP.NET WCF Service code is constructed and some of the things learned to get it to work correctly.