Flash Builder and ASP.NET, Part 2

In part 1, I describe the overall project and how each piece of this puzzle is linked. In part 2, I’ll describe how the ASP.NET back end is constructed and some of the lessons I learned along the way with providing data calls over a WCF service.

After setting up my database and project, I was able to generate the local objects via .NET 3.5’s ADO.NET Entity Framework. EF is an ORM similar to LINQ, but not limited to MSSQL as it’s backing database. In this case, I’d rather use LINQ to SQL since it’s easier to use, but Entity Framework is a requirement set by the client.

When you generate your objects with Entity Framework, it’s important to make sure that you’ve setup your relationships beforehand. The best way to do this is in the MSSQL designer, where you can actually drag your relationships between tables. MSSQL will then create the foreign key relationships for you and also ask how it should delete related information if the primary source is deleted first. We call this cascading.

If you do this before hand, you’ll save yourself time trying to do it in Entity Framework. It’s best just to let Entity Framework do what it’s good at and that’s generating objects and all the magic to pull your data into some usable C# objects.

The second piece of this ASP.NET puzzle is the WCF Services. WCF Services are split into two parts: an interface and class. The interface is like any other class interface, where you define the methods available in the class and what they should return. In the case of WCF Services, the interface is where you’ll define attributes to the class and methods. When you write these classes, Visual Studio will do a lot of the leg work for you, if you just select the WCF Service class template from the new item selector.

The WCF Service interface and class are the business layer for the whole MVC. This is where, if you need to modify the data before it comes in or goes out, you’d do that kind of work.

In the CRUD paradigm, this is what the R part would look like in the interface:

[ServiceContract]
public interface IUsers
{
[OperationsContract]
List<User> retrieve();
}

and the class:

public class Users : IUsers
{
MyEntityFramework db = new MyEntityFramework();
public List<User> retrieve()
{
return db.Users.toList();
}
}

Pretty easy.

What all this does is tell ASP.NET how it should handle calls back and fourth and what it is responsible for. It also will tell any other language how to consume data and how it should talk to ASP.NET when transacting information.

When you generate and write your WCF Services, Visual Studio goes ahead and handles some of the definitions needing to be made in the web.config file.

The latest and greatest of .NET services consume data over SOAP 1.2, but in the case of Flex, it will only do 1.1. This is where you have to tell the web.config file how to handle that kind of call.

This is what a service call looks like in the web.config:

It should look like this, provided you want to have both 1.2 and 1.1. calls available:

The major differences here is the addition of another endpoint, plus the definition of soap12 and soap11 in the address attributes. Without these additions, Flex will not consume your WSDL.

Once you’re WCF Services are written, you’re ready to test. When you visit your .svc page in a browser, you should be given a link with an ending ?WSDL in the query string. This is what any application will need, if it intends to consume data via WCF.

Now, with everything in place, your Flex app is ready to start consuming data and that’s coming up in the next part.