OK.  Here's the challenge.  We have 3 physical tiers. The database tier, the middle tier, and the front end tier.  These aren't the best names for them but that's what they are.  The database and middle can talk to each other, the middle and front end can talk to each other, but the front end cannot physically touch the database.  Fine. 

So the challenge is how do you ensure a "Web 2.0" experience on the front end without touching the database?  Defining "Web 2.0" is a start.  For me, that's a responsive, intuitive interface.  No delay in ANYTHING.  Immediate results of your actions, you click save, I wanna see green or some sort of fireworks indicating success within nanoseconds of pressing the save button.

We're moving forward with a strategy of delivering some of the front end content from the middle tier.  The middle tier holds the rules, in this design anyway.  So if a user identified on the front end requests something or performs some action, the middle tier decides whether that user can do whatever they tried.  It's also a way of the middle tier deciding, based on the user in context, what that user gets to see on their front end. 

Other strategies have been suggested, like why not just have the middle tier execute sql against the database on behalf of the front end, return data and let the front end figure out business rules and what the user gets to see.  So If the front end needs data, it makes a call into the middle tier, and says "Get me stuff".  The middle tier says, "OK, lemme ask the database for it and i'll get back to ya in a quick moment".  Fair enough.  But then you get into the details of how that data is marshalled back and forth. DataSets? How do you fill datasets? This starts getting into the realm of writing your own sql, which is NOT what I'm in the business of doing.  There are tools that do that better than me, and I plan on utilizing those tools.

In the spirit of keeping an open mind, I'm gonna start from the basics, straight up sql from the middle tier to the database, and plain ol web service calls from the front end to the middle tier.  I'll post that guy in a few.

As I'm adding tests to HyperActive, I've noticed something.  I'm falling asleep! OMG this is boring, and a good reason why not to do TAD(Test After Development).  It's a snoozer :( Live and learn.

Here's another test:

[Test]
public void VerifyInheritsFrom()
{
  NamespaceDeclaration nsdecl =
    new NamespaceDeclaration("TestContainer");

  nsdecl.AddClass("Manager")
    .InheritsFrom(nsdecl.AddClass("Employee"));

  using (DomTester dom = new DomTester(nsdecl))
  {
    Assert.IsTrue(dom.Type("Manager").InheritsFrom("Employee"));
  }
}


1
2
3
4
5
6
7
8
9
10
11
12
13
14

That snippet tests the compiled version of the following source that was generated:

I've mentioned testing generated code before.  I'm getting ready to release the last visual studio 2005 version of HyperActive as of this Friday and thought it would be good to finally get a handle on the testing.  Most of the initial testing, I'm embarassed to say was visual, or testing the whole shebang against a database, see what broke, fix it, run the whole thing again, etc.  it was sooper lame.  So I wanted a way to not only test that I've generated the correct source code, I wanted to see if the source actually compiles; and furthermore I wanted to inspect the resulting assembly to determine if what I generated is actually in there.  So here's what my test looks like:

[Test]
public void VerifyAddAttribute()
{
  NamespaceDeclaration nsdecl =
    new NamespaceDeclaration("Test");

  nsdecl.AddClass("SuperAttribute")
    .InheritsFrom("System.Attribute");

  nsdecl.AddClass("Customer")
    .AddAttribute(new CodeDomTypeReference("Test.SuperAttribute"));

  using (DomTester dom = new DomTester(nsdecl))
  {
    Assert.IsTrue(dom.Type("Customer")
      .HasAttribute("Test.SuperAttribute"));
  }
}


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

If can print out the source code to the output window, it looks like this:

It's cool because it loads the assembly in it's own AppDomain.  What wasn't cool was when I was defining the attribute in the example above in the same class as the unit test.  When I ran the test it kept failing cuz it couldn't find something.  Yep, it couldn't find that stupid attribute I created in my test class.  So to fix the problem I just created the attribute in the same namespace that i need to test and KABLAM, now it knows where that attribute is located and passes.