Honestly, this post started off as a rant entitled “Is it Me, or is DB Development a Pain in the Ass?” about the sorry state of database development tools in Visual Studio. But in searching around on MSDN for information about the built-in “Database Project” type (which could more accurately be called “just a bunch of SQL scripts”), I stumbled across information about the Database Professionals edition of Visual Studio Team System. That’s right, I had forgotten that we shipped this late last year.

I short, VSTDB (or whatever the “official” acronym is) is 90% of what I was looking for in a DB dev tool. Sure, it’s not perfect, but it’s a massive improvement over the previous state of the art.

The primary feature of VSTDB is the ability to “build” your database the same way you build your code. You use lots of small scripts that get compiled together into a model (for lack of a better term) of the database as you’ve defined it. That model can be deployed to a new database instance or used to update an existing instance. You can also compare that model against an existing database in order to determine what’s changed and automatically build update SQL scripts for the DBA’s to run in the production environment (since you don’t want your developers doing that).

It takes a little getting used to, but the “lots of small scripts” approach has a lot of upside. If you have a table with a primary key, you’re supposed to define the primary key, indexes, constraints, triggers, etc. in separate scripts from table creation script. This makes things much easier when you’re trying to figure out what’s changed in your source control system.

VSTDB has a variety of other cool looking features like data generation and unit testing, but I haven’t really dug into them much yet. One thing that VSTDB supports that I wasn’t expecting was Service Broker! SQL Management Studio has limited SSB support – if you want to create new SSB objects you have to write the DDL directly. VSTDB requires you to write the SSB DDL also (it makes you write DDL for everything, see below) but it at least has templates for all the SSB object types. Very Cool!

Of course, there are always things that could be improved. The T-SQL editor does syntax highlighting but not IntelliSense. It doesn’t support the existing visual database tools like the Table Designer. And while you can build T-SQL stored procs, functions, types, etc, VSTDB doesn’t support the development of managed SQLCLR stored procs, et.al. Things to work on for v2, I suppose.

If you’re using VS Team Suite, you can download an add-on that adds VSTDB functionality to your existing VSTS installation. It’s only 8MB, so it’s definitely the way to go for Team Suite users.

• USC is in the Sweet 16. Not sure when that’s ever happened before.
• Politics 2.0 Watch: The rise of political blogs in main stream media reporting. Check out what the LA Times has to say about Talking Points Memo. 2008 is going to be interesting and ugly.
• Jeffrey Palermo wrote that Scott Guthrie showed him a prototype web MVC framework for ASP.NET. Looking forward to seeing that. I thought it was interesting that Jeff described web MVC as “like Rails and MonoRail”. Didn’t Web MVC initially gain popularity on Java with toolkits like Struts and Spring? (via Larkware News)
• For reasons that can’t be explained, I haven’t read Eric.Weblog() in quite a while. My loss. His post on Boundaries was both thought provoking and hilarious, a hard combo to achieve in practice.
• New versions of Expression Design (Beta 2) and Expression Blend (Release Candidate) are available.
• Martin Fowler writes about being Transactionless. I like to see people thinking this way, because I don’t believe transactions across services is feasible or loosely coupled. However, I still think you should use transactions inside the service. Also, I gotta wonder how much time all that error checking logic you have to write takes if you’re not using transactions. What’s the tradeoff?

Sort of late this morning due to back to back meetings…

• I seem to have stirred up a bit of a hornet’s nest with my “kinda surprising that no other mainstream language has done this before” comment. Dennis Hamilton and Mike Parsons both asked about other dynamic languages like Javascript and Python in my comments. To be clear, the ability to add a new method to a specific object instance is fairly common in dynamic languages. Extension methods in C#3/VB9 is a different capability – it only supports adding new methods to a class, not to specific object instances. I’m not sure what dynamic languages other than Ruby supports adding new methods to both object instances and classes, but I’m sure they’re out there.
• Some anonymous commenter asked “why invent another language for PowerShell if there are so many great popular languages already in existance [sic]?” I can’t speak for the PowerShell team, but I think they were better off inventing a new language specificly designed for their scenario than they would have been shoe-horning in existing lanugage. To their credit, it looks like the PS team took great care to make the PS lanugage accessable by leveraging common syntax and idioms from other shell programming environments. I’m not a shell programming expert, but isn’t PS more a variant of shell languages that have come before than a brand new language?
• I want a “Works on My Machine” T-Shirt.

Brad Wilson and Scott Hanselman took me to task for my comment the other day that no “mainstream” language had implemented extension methods:

How mainstream is Ruby on Rails for you? Ruby is a full fledged dynamic language. No hacks for “extension methods” (Brad)

Ya, I kind of blanched at that statement too…method_missing is pretty mainstream… (Scott)

They’re right, Ruby does support the addition (and redefinition I think) of methods on a class at any time. There’s a sample of this in the Classes and Objects chapter of Programming Ruby (aka the pick-axe book) where they add a basic documentation facility “available to any module or class” in Ruby by adding a doc instance method to the Module class.

class Module
  @@docs = Hash.new(nil)
  def doc(str)
    @@docs[self.name] = str
  end
  def Module::doc(aClass)
    # If we’re passed a class or module, convert to string
    # (‘<=’ for classes checks for same class or subtype)
    aClass = aClass.name if aClass.type <= Module
    @@docs[aClass] || “No documentation for #{aClass}”
  end
end

Given how Ruby classes are defined, I think the newly added methods have access to the private data of the class. Extension methods in C#3/VB9 only have access the public interface of the object. But that’s a fairly minor difference.

FYI, Powershell can do this as well, though not as succinctly as Ruby. Scott has an example how you can add a DatePhotoTaken property to System.IO.FileInfo using Omar Shahine’sPhotoLibrary project.

Chalk this up to my continuing ignorance of dynamic languages. I’m working on it, albeit slowly.

Nick Allen asked on his blog about how people would like to see SSB and WCF work together. He’s already heard these from me, but I figured I’d put them out there for everyone to see and debate. Plus, I had several beers last night at the MVP dinner, so this is likely to be more coherent than I was yesterday! 😄

1. Are you interested in SSB because you’d like to have your service closer to the database? How close is close enough to the database?

I’ve first blogged about the endangered middle tier almost three years ago. My point at the time was that as you break your monolithic system up into services, the vast majority of those services won’t need to scale out. You performance gets better the closer you are to the data. If you don’t need to scale out, why not get the maximum boost by running in the database process itself?

Furthermore, in large IT shops, the database files are stored out on the SAN rather than on hard drives attached to the database server itself. That means the database server is effectively stateless. Why add a second stateless tier if you don’t need scale out? If you need more performance in a given service, you can detach the database file from it’s current SQL server box and attach it on another more beefy SQL server box without physically moving the database files at all. This enables what I call the “Star Trek Effect”, where you can shift computing power where it is needed most (more power to the payroll system!).

Of course, if you’re going to move the service, you do need to bring it down for a short time. That implies a need for durable messaging so that service consumers aren’t affected by the brief service interruption. Which brings us to…

2. Are you interested in SSB because you need durable, duplex messaging between two services? Do you need exactly-once-in-order message delivery?

Yes. SSB has a bunch of other nice features, but durable duplex messaging is what I need the most. Exactly-once-in-order is also fairly critical, though there may be scenarios where it’s not really necessary. Those are the exception, not the rule however.

Doesn’t WS-RM already do EOIO already?

3. Are you interested in using SSB from WCF because you want a better asynchronous messaging experience than MSMQ? What makes you prefer SSB to other queuing products?

My primary problem with MSMQ for the problems I’m tasked with solving is that MSMQ is one way while SSB supports duplex messaging. You could do duplex messaging with MSMQ if you didn’t mind managing multiple queues (one for each side of the conversation) but SSB does this for you for free. I’m sure there are scenarios where pure one-way messaging are useful, but they are few and far between in my day job.

Furthermore, SSB has the explicit idea of a service instance (they call it a conversation group) which MSMQ lacks. SSB’s implementation is conceptually similar to the new WCF/WF integration work in the latest Orcas CTP.

Finally, SSB uses logical naming. You have conversations between services, but services get mapped to physical addresses at the routing layer. This allows services to move around more easily (see the “Star Trek Effect” in #1 above). Both MSMQ and WCF use physical addresses, which makes them much more difficult to move.

4. Are you interested in having your data contracts defined in WCF, SQL, or both?

I like WCF’s data contract infrastructure. We did a early prototype long-running service with both WCF and SSB. the messaging stack code was obviously different, but we used the exact same data contract code. I even wrote some code to automatically deserialize the SSB message by mapping the SSB message type to a data contract.

I want my services to run inside the database, but that doesn’t mean I want to write them in T-SQL. Personally, I’m much more productive in C# and/or WF. So WCF data contracts are fine by me.