At Microsoft's Tech·Ed 2006 conference in Boston this week the pre-conference keynote on Sunday night discussed little of importance to developerswhich was a good thing, as many attendees didn't arrive in time to hear it. Despite that, the breakout sessions contained plenty for developers to get excited about. Name changes, however necessary, aren't among them. In an orgy of nomenclature revision, Microsoft has eliminated WinFx as a separate product name, announcing it would henceforth simply be part of the .NET Framework 3.0, due to ship with Vista. Monad has become Windows PowerShell, InfoCard has changed to CardSpace, and Content Management System has merged with Sharepoint 2007.
Entity Data Model
Brand-new names have appeared as well. First, and perhaps most intriguing, is a concept called the Entity Data Model (EDM), which is part of a future version of ADO.NET, currently labeled "vNext." In a session called "Next-generation Data Access in .NET Applications with ADO.NET vNext," Pablo Castro discussed how ADO.NET will help solve some pernicious database problemsincluding the oft-requested object/relational mapping capabilityby letting developers visually create entities, which are essentially client-side "views" of database data constructed from fields in one or more database tablesapplication-level views of the data that embody the entities the application deals with.
For example, you might construct a Customer entity that includes contact information, meeting dates, orders, etc., from several different database tables. ADO.NET vNext generates the SQL JOIN statements to retrieve the entity data. It can also automatically generate CLR classes that represent the entity itself (the entire set of rowsa Customers collection class) and the individual rows (a Customer class) retrieved, much like .NET today can generate DataSet classes and schema automatically. Putting developers (rather than database administrators) in charge of these views and placing them on the client provides several huge advantages:
- Developers can query the entities in either a data-centric (rows/columns) or an object-centric way.
- For data-centric queries, Microsoft has created a SQL-like language called Entity SQL.
- For object-centric queries, developers can use Language-integrated Query (LINQ).
- Whether developers update entities through Entity SQL or using generated objects, entities (unlike many views) are fully updatable. Behind the scenes, vNext translates Entity SQL, LINQ queries, or updated objects back to standard SQL with the proper syntax and joins to get or update data in the underlying data store.
- This translation layer can make working with entities truly database-independent. Microsoft will support SQL Server, SQL CE, Oracle, and perhaps other databases out-of-the-box. You configure the database connection that ADO.NET vNext uses in a configuration file. Because developers don't interact directly with the SQL at all, and vNext understands the SQL syntax for different databases, changing back-end stores is a simple configuration change.
- Developers can easily choose between working with entity data in row/column form or in object formin fact, they can use both within a single application. For example, it might be useful to list multiple Customers in a grid (data-centric) for reports, while it might be more useful to treat them as objects for business logic purposes.
- Best of all, perhaps, because ADO.NET knows the entity schema, it can provide IntelliSense and compile-time type-checking for the queries you write.
- Finally, entities are inheritable objects. For example, you might have a PreferredCustomer entity that inherits from Customer, making it very easy to differentiate between the two programmatically.
Despite such a strong move to isolate server-side databases, Microsoft hasn't forgotten database developers, announcing a new CTP of Visual Studio Team Edition for Database Professionals, with tools that simplify and automate database development, testing, and change management.
WinFS, cut from the first version of Vista, isn't dead; it's still being improved. Shan Sinha, a Program Manager on the WinFS team, showed off the newest features, and promised a second beta later this year. WinFS wraps the tried and too-familiar NTFS file system in a relational database, providing new and revolutionary relational abilities to the Windows file system. Doing that has far-reaching implications, and presents huge technical hurdles. For example, a relational file system must manage its own indexes, backup, and recovery, and must do so both invisibly and with no human intervention (no database admin). Despite adding new and integrated file system capabilities, it must maintain file-level compatibility with earlier versions, so that existing programs don't break, and it must be able to maintain the new information and relationships across backups. From the demos though, it looks as if Microsoft has conquered the problems. In one demonstration, Shan destroyed the data on a disk sector, then walked the audience through the automatic recovery process. Very impressive.
Another nearly-baked technology useful for both administrators and developers is Windows PowerShell (formerly Monad), which you can download in RC1 form today. PowerShell is a new command-shell language that bears almost no resemblance to the familiar command prompt.
Learning PowerShell requires some effort, but that will pay off in spades. Jeffrey Snover, a Windows PowerShell architect, explained in his session Tuesday that PowerShell is an object-based scripting language with the following advantages:
- Interactive capabilities
- The ability to stitch together very powerful capabilities with utilities
- Assemble various commands into scripts
- Generalize (parameterize) those scripts
- Produce production-quality results
- Deliver signed, secure scripts
Snover said that his team wanted PowerShell to have the interactivity of BASH and the programmability of PERL, command-parity with MMCs (meaning you should be able to do everything you can do today through the MMC snap-ins), all the capabilities of the cmd prompt, all the scripting capabilities of WSH (VBScript and Jscript), and much of the power of the .NET framework on top of that. They seem to have achieved those goals.
If you download and install PowerShell, when you launch it you get a plain text-window prompt, for example:
Type "dir" and press Enter. You'll get what is seemingly a list of files, just as you would have with cmd (see Figure 1
); however, each of the items in that list is actually a FileInfo object.
Figure 1. PowerShell Dir Command: The command appears to simply print a list of files, but actually returns a list of FileInfo objects.
Figure 2. PowerShell Drives: The figure shows a list of drives generated by the Get-PSDrive command.
You can assign the returned file list to a variable:
PS C:\Demo> $f = dir
Subsequently, you can get the file count with:
PS C:\Demo> $f.count
PowerShell treats the active variables as a drive. To see the list of available drives, use the command get-PSdrive, which produces the output shown in Figure 2
Only two of those "drives" (the C and D drives) are what you'd normally think of as drives. The others are named drives that let you navigate through PowerShell's shortcut "Alias" list, the certificates available on your machine (CERT), the list of environment variables (ENV), the Registry (HKCU, HKLM), and the list of variables active in PowerShell (Variable). You change between drives using the Set-Location command.
Many commands have shortcuts or "aliases." For example, the familiar chdir (or just cd) are aliases for Set-Location. You can see a list of these by changing to the Alias drive, and listing the content (see Figure 3).
Beginners might find it more convenient if that list were sorted by Name rather than by Definition. No problem. Simply pipe the output to the Sort command:
PS Alias:\> dir | sort name
Note that you don't have to fiddle around with column positions, you can simply sort by whichever output criteria (in this case the Name column) that you wish. Doing that gives you the list in Figure 4
Figure 3. PowerShell Aliases: The Alias drive contains a list of shortcuts or aliases currently available in PowerShell.
Figure 4. Sorting Output: You can sort PowerShell output by piping it to the Sort command.
These examples don't even begin to scratch the surface. I urge you to explore PowerShell on your own. Snover admonished attendees to remember four things:
- Get-Commandgets a list of "Cmdlets" that you can use to explore.
- Get-Helpgets help on a topic. For example, Get-Help Get-* retrieves help on all the commands that begin with "Get-" (yes, there's extensive wildcard support).
- Get-PSDrivereturns the list of drives on your system as discussed earlier.
- Get-Memberreturns the "members" (properties, methods, etc.) of an object.
With those in hand, you'll be a PowerShell expert in no time.
Microsoft provided all attendees with Office 2007 Beta 2, which replaces Office's familiar nested standard menus with a set of tabs and "ribbons" (see Figure 5). Microsoft claims this changealong with context-sensitivity that displays special functions when you select objects such as images, graphs, etc.exposes more of Office's features to users. Perhaps so, but (at least in the beta) some of the features I commonly use weren't available from the ribbon, or at least, I haven't found them yet. For example, to run a Macro (formerly available through the Tools>Macro>Macros menu), you now have to first display the hidden-by-default "Developer" tab, a feature which is itself hidden under a button on the "Office" dropdown menuwhich doesn't look like a menu at all. But other hidden features are welcome. For example Word Count is now always-available from the status bar. Despite some initial frustrations, I suspect I'll eventually like the new layout better.
|Figure 5. Tabs and Ribbons: Often used features on Office 2007 are parceled out onto tabs instead of toolbars. Here Microsoft Word is shown with the "Home" tab activated and several ribbons including Clipboard, Font, and Paragraph.|
And, of course, it's both customizable and programmable. Better yet, it's programmable through configuration. By writing some relatively simple XML, you can add your own custom tabs and tools, or control the built-in features. For those Office developers who want to restrict users' actions, a single command called "StartFromScratch" removes all the built-in ribbon features. You can build from there, re-enabling the built-in commands and tools you want users to have, overriding their default actions with custom code, providing a completely custom set of tabs and tools, or giving them a mixture of any of these options.
Users can even customize the ribbons you provide, creating their own preferred feature collections in exactly the same way they customize the built-in features. And this all works the same way across all the Office products. For more information, see msdn.microsoft.com/office/tool/ribbon/.