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:
<service behaviorConfiguration=”Flex_Backend.Services.UsersBehavior” name=”Flex_Backend.Services.Users”>
<endpoint address=”” binding=”wsHttpBinding” contract=”Flex_Backend.Services.IUsers”>
<identity>
<dns value=”localhost” />
</identity>
</endpoint>
<endpoint address=”mex” binding=”mexHttpBinding” contract=”IMetadataExchange” />
</service>
It should look like this, provided you want to have both 1.2 and 1.1. calls available:
<service behaviorConfiguration=”Flex_Backend.Services.UsersBehavior” name=”Flex_Backend.Services.Users”>
<endpoint address=”soap12” binding=”wsHttpBinding” contract=”Flex_Backend.Services.IUsers”>
<identity>
<dns value=”localhost” />
</identity>
</endpoint>
<endpoint address=”soap11” binding=”basicHttpBinding” contract=”Flex_Backend.Services.IUsers”>
<identity>
<dns value=”localhost” />
</identity>
</endpoint>
<endpoint address=”mex” binding=”mexHttpBinding” contract=”IMetadataExchange” />
</service>
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.
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:
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.
