Joe Blogs

I recently took to converting a small side project from ASP.NET Dynamic Data, Web Services and WPF to ASP.NET MVC, ADO.NET Data Services and the Entity Framework.  The small project involved a small database, an administration web site and a smart client run over the Internet.  The dataset is small, the project is simple – just a single data source and no need for large enterprise style long term architectural planning.  But the goal is to gain some perspectives on the new technology and how it can be used in large scale multi-tier, multi-solution, multi-data source, enterprise wide architecture.  I’m trying to gauge how some of the new tools and wizards around this technology can be used alongside an enterprise architecture and common conceptual model.

This first tentative step is just one day in at this point.  Plus, this one day is with the distraction of the last few episodes of Battlestar Galactica on in the background.  So, please take any rants with a pinch of salt – it’s a work in progress. 

The Plan and the Tools

This small application has a small SQL Server database at its heart.  The data in the database is administered by an ASP.NET website.  The first step was to convert this from classic WebForms to ASP.NET MVC based on an Entity Framework data model.  The steps for this are covered well by the http://www.asp.net tutorials.  ASP.NET MVC by default does not give you the scaffolding that ASP.NET Dynamic Data gives you – but there’s a tool available that offers this functionality.  I stuck with the standard wizards and created my own views to edit/list/create/delete the four tables in the database.

The next step was to expose this data as a webservice.  I wanted to make this a URL friendly REST web service, so I added an ADO.NET Data Service to the ASP.NET project and pointed the service at the existing Entity Framework model.

Lastly, I needed to update the Rich clients to use the new web service.  To do this I used the client proxy "Add Service Reference” to the WPF app and also created a Silverlight 2 app using the same reference.

Entity Framework, Models and LINQ

In most scenarios having a single data source with the same schema as your application domain model is fine.  Your entity objects definitions are driven by your database design.  Entity objects are just a way of talking to your database. 

In enterprise architecture it can become much more complicated.  A typical ‘solution’ may have several data sources: – a legacy database, a new database that doesn’t quite cover all the new features that the old one did, a real-time transaction feed over a message bus, a security profile database, a vendor API onto another server etc.   On top of this there may be dozens of these solutions across multiple departments.  For Enterprise Architecture a more Domain Driven approach is required.  The Domain Model is built out of the business and not out of IT. 

Out of the box, the default use of the Entity Framework is in relation to a single data source.  There are some options for field mapping (new names, some versatility with data types etc) – but this is limited. The Entity Framework can support a conceptual model approach.  The EDMX file is composited of the SSDL (for storage), CSDL (for the conceptual model) and a mappings section bringing the two together. Unfortunately, the IDE doesn’t really support a CSDL only file.  It’s also not clear if a CSDL file can be used without the other components (I mean non-generated mapping and non-relational data source).

When you use the Entity Framework with a single relational datasource you get a generated set of entity objects (derived from EntityObject).  Diego Vega explains the layers of the Entity Framework nicely.  So far I don’t see this being extensible enough to provide support for a conceptual domain model approach, with multiple mappings to relational and non-relational data.  I guess this is where Oslo comes in.

A more general comment about technologies like the Entity Framework is that the assumption is the domain container is also the primary access point to the underlying data store.  A LINQ query on the ‘Orders’ collection on the container will actually go out to the preconfigured database.  From a multi-data source conceptual model perspective, I would prefer to see these Entity containers that represent the data source use conceptual data model classes rather than their own generated classes.  The Wizard for adding Web Service references has this feature (being able to reuse existing referenced types).

ASP.NET MVC and the Fork in the Road

I think MVC is generally easy to grasp.  The tutorial videos on www.asp.net are great, particularly this 12 minute video introduction.  I like the fact that MVC is decoupled from the underlying model and data access.  There are no real assumptions on LINQ to SQL, Entity Framework or even LINQ at all.  The Controller is in charge of this – as it should be.

On the downside, I got the ‘fork in the road’ feeling – even though Hybrids are possible, as detailed by Scott Hanselman.  I’m just one day in, but I totally failed to get an AJAX Web Service call to work using the DataView (using preview 4 of the ASP.NET AJAX bits).  This same call worked fine outside my view page.  I’m guessing it was a routed URL issue – and I will go back to review the ‘ignore route’ calls.  I don’t think there is anything inherently incompatible here, I just wish that there were fewer “New Project” options and more “Add File” options.  These technologies should be a toolbox and easy to pick and mix.

ASP.NET MVC and Entity Framework Foreign Keys

One pain point with MVC and the Entity Framework was around creating and editing relationships (foreign key columns).  The Entity Framework chooses to represent foreign key fields as an EntityRelationship object.  The default view creation fails and ignores these fields.  You can create a dropdownlist by hand, but the resulting value of the foreign key cannot be automatically mapped to the object (there’s no field to put it into).

There are a couple of solutions to this.  One solution that I’ve seen used is to use a ViewModel over the entity object.  Then create the view based on the viewmodel and use a local field to store the foreign key.  The other solution is to use a custom Controller function to pass back the newly created object, containing a parameter for the foreign key.  I’m not totally happy with either approach, but I think this is really a problem with the default generated Entity Model more than an MVC issue.

The Client Continuum

ADO.NET Data Services are great.  I especially like the client side support for LINQ – effectively giving you LINQ to REST.  I’m not sure how standard the URL syntax is (this is REST, there are no standards) but this is a huge time saver and a big boost for shops using the same technology platform on the client and server.

This ‘client continuum’ has massive potential.  This is especially important in areas where there is a lot of processing and the need to be flexible where that processing is run.

My plan for day#2 is to continue to refactor the code and focus on the client.  At the moment, my REST service reference in the Silverlight 2 and WPF client is using its own version of the entity objects that exist on the server.  There is no real code share (therefore hindering my ability to share other code that is built on the common conceptual model).  I want to be able to create a set of conceptual model classes, use them for the client side REST proxy and also use the same code on the server side in place of the generated Entity Framework classes.

I will cover this an share some code in a follow-up post. 

More on Twitter: @woodjoe.