As many of my friends know I’ve been working hard on a new book for O’Reilly called Getting Started with Metro Style Apps. This book is written for existing .NET developers who are interested in the changes introduced with the release of Windows 8. This book is intended to be a guide to developing complete Metro style apps end-to-end. If you have an idea or you are just curious about the platform, this is the place to start.

In addition to announcing my cover art (an alligator, yay), I’m happy to announce that the first few chapters are now available for download via the O’Reilly Early Release program at http://shop.oreilly.com/category/early-release.do. You can also see the work in progress and provide feedback via the O’Reilly Open Feedback Publishing System at http://ofps.oreilly.com/titles/9781449320553/

New Spatial Data Classes

The three new spatial data classes in SQL Server 2012 are:

• Circular strings
• Compound curves
• Curve polygons

All three of these shapes are supported in WKT, WKB, and GML by both the geometry and geography data types, and all of the existing methods work on all of the new circular shapes. My previous post, Geospatial Support for Circular Data in SQL Server 2012 covers these new spatial classes in detail, and shows you how to use them to create circular data. This post focuses on additional spatial features that are new in SQL Server 2012.

New Spatial Methods

Let’s explore a few of the new spatial methods. Some of these new methods complement the new curved shapes, while others add new spatial features that work with all shapes.

The STNumCurves and STCurveN Methods

These two methods can be invoked on any geometry or geography instance. They can be used together to discover information about the curves contained within the spatial instance. The STNumCurves method returns the total number of curves in the instance. You can then pass any number between 1 and what STNumCurves returns to extract each individual curve, and thus iterate all the curves in the instance.

For example, the WKT string CIRCULARSTRING(0 4, 4 0, 8 4, 4 8, 0 4) defines a perfect circle composed of two connected segments; 0 4, 4 0, 8, 4 and 8 4, 4 8, 0 4 (the third coordinate 8 4 is used both as the ending point of the first arc and the starting point of the second arc. The following code demonstrates how to obtain curve information from this circular string using the STNumCurves and STCurveN methods.

-- Create a full circle shape (two connected semi-circles)
DECLARE @C geometry = 'CIRCULARSTRING(0 4, 4 0, 8 4, 4 8, 0 4)'

-- Get the curve count (2) and the 1st curve (bottom semi-circle)
SELECT
  CurveCount = @C.STNumCurves(),
  SecondCurve = @C.STCurveN(2),
  SecondCurveWKT = @C.STCurveN(2).ToString()

This query produces the following output:

CurveCount SecondCurve                      SecondCurveWKT
---------- -------------------------------- ------------------------------
2          0x000000000204030000000000000... CIRCULARSTRING (8 4, 4 8, 0 4)

You can see that STNumCurves indicates there are two curves, and that STCurveN(2) returns the second curve. If you view the results in the spatial viewer, you’ll see just the top half of the circle. This is the semi-circle defined by the second curve, which is converted back to WKT as CIRCULARSTRING (8 4, 4 8, 0 4). Notice that this represents the second segment of the full circle.

The BufferWithCurves Method

SQL Server 2008 introduced the STBuffer method which “pads” a line, effectively converting it into a polygon. If you look closely at the resulting polygon shapes in the spatial viewer, it appears that the points of each line string (including the mid points) are transformed into rounded edges in the polygon. However, the rounded edge look is actually produced by plotting many short straight lines that are clustered very closely together, presenting the illusion of a curve. This approach is necessary since curves were not previously supported before SQL Server 2012 (but the STBuffer method was).

Clearly, using native curve definitions in a curve polygon is more efficient than clustering a multitude of straight lines in an ordinary polygon. For backward compatibility, STBuffer continues to return the (inefficient) polygon as before. So SQL Server 2012 introduces a new method, BufferWithCurves, for this purpose. The following code uses BufferWithCurves to pad lines using true curves, and compares the result with its straight-line cousin, STBuffer.

DECLARE @streets geometry = '
 GEOMETRYCOLLECTION(
  LINESTRING (100 -100, 20 -180, 180 -180),
  LINESTRING (300 -300, 300 -150, 50 -50)
 )'
SELECT @streets.BufferWithCurves(10)

SELECT
  AsWKT = @streets.ToString(),
  Bytes = DATALENGTH(@streets),
  Points = @streets.STNumPoints()
 UNION ALL
 SELECT
  @streets.STBuffer(10).ToString(),
  DATALENGTH(@streets.STBuffer(10)),
  @streets.STBuffer(10).STNumPoints()
 UNION ALL
 SELECT
  @streets.BufferWithCurves(10).ToString(),
  DATALENGTH(@streets.BufferWithCurves(10)),
  @streets.BufferWithCurves(10).STNumPoints()

Here is the resulting shape returned by the first SELECT statement (the collection of padded line shapes generated by BufferWithCurves):

As with STBuffer, the new shapes have rounded edges around the points of the original line strings. However, BufferWithCurves generates actual curves, and thus, produces a significantly smaller and simpler polygon. The second SELECT statement demonstrates by comparing the three shapes—the original line string collection, the polygon returned by STBuffer, and the curve polygon returned by BufferWithCurves. Here are the results:

AsWKT                                                        Bytes  Points
-----------------------------------------------------------  -----  ------
GEOMETRYCOLLECTION (LINESTRING (100 -100, 20 -180, 180 -...  151    6
MULTIPOLYGON (((20.000000000000796 -189.99999999999858, ...  5207   322
GEOMETRYCOLLECTION (CURVEPOLYGON (COMPOUNDCURVE ((20.000...  693    38

The first shape is the original geometry collection of line strings used for input, which requires only 151 bytes of storage, and has only 6 points. For the second shape, STBuffer pads the line strings to produce a multi-polygon (a set of polygons) that consumes 5,207 bytes and has a total of 322 points—a whopping 3,448 percent increase from the original line strings. In the third shape, BufferWithCurves is used to produce the equivalent padding using a collection of curve polygons composed of compound curves, so it consumes only 693 bytes and has only 38 points—a (relatively) mere 458 percent increase from the original line strings.

The ShortestLineTo Method

This new method examines any two shapes and figures out the shortest line between them. The following code demonstrates:

DECLARE @Shape1 geometry =
 'POLYGON ((-20 -30, -3 -26, 14 -28, 20 -40, -20 -30))'

DECLARE @Shape2 geometry =
 'POLYGON ((-18 -20, 0 -10, 4 -12, 10 -20, 2 -22, -18 -20))'

SELECT @Shape1
UNION ALL
SELECT @Shape2
UNION ALL
SELECT @Shape1.ShortestLineTo(@Shape2).STBuffer(.25)

This code defines two polygons and then uses ShortestLineTo to determine, generate, and return the shortest straight line that connects them. STBuffer is also used to pad the line string so that it is more clearly visible in the spatial viewer:

The MinDbCompatibilityLevel Method

With the added support for curves in SQL Server 2012 comes support for backward compatibility with previous versions of SQL Server (2008 and 2008 R2) that don’t support curves. The new MinDbCompatibilityLevel method accepts any WKT string and returns the minimum version of SQL Server required to support the shape defined by that string. For example, consider the following code:

DECLARE @Shape1 geometry = 'CIRCULARSTRING(0 50, 90 50, 180 50)'
DECLARE @Shape2 geometry = 'LINESTRING (0 50, 90 50, 180 50)'

SELECT
 Shape1MinVersion = @Shape1.MinDbCompatibilityLevel(),
 Shape2MinVersion = @Shape2.MinDbCompatibilityLevel()

The MinDbCompatibilityLevel method returns 110 (referring to version 11.0) for the first WKT string and 100 (version 10.0) for the second one. This is because the first WKT string contains a circular string, which requires SQL Server 2012 (version 11.0), while the line string in the second WKT string is supported by SQL Server 2008 (version 10.0) and higher.

The STCurveToLine and CurveToLineWithTolerance Methods

These are two methods you can use to convert curves to roughly equivalent straight line shapes. Again, this is to provide compatibility with previous versions of SQL Server and other mapping platforms that don’t support curves.

The STCurveToLine method converts a single curve to a line string with a multitude of segments and points that best approximate the original curve. The technique is similar to what we just discussed for STBuffer, where many short straight lines are connected in a cluster of points to simulate a curve. And, as explained in that discussion, the resulting line string requires significantly more storage than the original curve. To offer a compromise between fidelity and storage, the CurveToLineWithTolerance method accepts “tolerance” parameters to produce line strings that consume less storage space than those produced by STCurveToLine. The following code demonstrates by using both methods to convert the same circle shape from the previous STNumCurves and STCurveN example into line strings.

-- Create a full circle shape (two connected semi-circles)
DECLARE @C geometry = 'CIRCULARSTRING(0 4, 4 0, 8 4, 4 8, 0 4)'

-- Render as curved shape
SELECT
  Shape = @C,
  ShapeWKT = @C.ToString(),
  ShapeLen = DATALENGTH(@C),
  Points = @C.STNumPoints()

-- Convert to lines (much larger, many more points)
SELECT
  Shape = @C.STCurveToLine(),
  ShapeWKT = @C.STCurveToLine().ToString(),
  ShapeLen = DATALENGTH(@C.STCurveToLine()),
  Points = @C.STCurveToLine().STNumPoints()

-- Convert to lines with tolerance (much smaller, much fewer points)
SELECT
  Shape = @C.CurveToLineWithTolerance(0.1, 0),
  ShapeWKT = @C.CurveToLineWithTolerance(0.1, 0).ToString(),
  ShapeLen = DATALENGTH(@C.CurveToLineWithTolerance(0.1, 0)),
  Points = @C.CurveToLineWithTolerance(0.1, 0).STNumPoints()

The query results show that the original circle consumes only 112 bytes and has 5 points. Invoking STCurveToLine on the circle converts it into a line string that consumes 1,072 bytes and has 65 points. That’s a big increase, but the resulting line string represents the original circle in high fidelity; you will not see a perceptible difference in the two when viewing them using the spatial viewer. However, the line string produced by CurveToLineWithTolerance consumes only 304 bytes and has only 17 points; a significantly smaller footprint, paid for with a noticeable loss in fidelity. As shown by the spatial viewer results below, using CurveToLineWithTolerance produces a circle made up of visibly straight line segments:

The STIsValid, IsValidDetailed and MakeValid Methods

Spatial instance validation has improved greatly in SQL Server 2012. The STIsValid method evaluates a spatial instance and returns a 1 (for true) or 0 (for false) indicating if the instance represents a valid shape (or shapes). If the instance is invalid, the new IsValidDetailed method will return a string explaining the reason why. The following code demonstrates.

DECLARE @line geometry = 'LINESTRING(1 1, 2 2, 3 2, 2 2)'

SELECT
 IsValid = @line.STIsValid(),
 Details = @line.IsValidDetailed()

This line string is invalid because the same point (2 2) is repeated, which results in “overlapping edges,” as revealed by the output from IsValidDetailed:

IsValid  Details
-------  -----------------------------------------------------------------
0        24413: Not valid because of two overlapping edges in curve (1).

SQL Server 2012 is more tolerant of invalid spatial instances than previous versions. For example, you can now perform metric operations (such as STLength) on invalid instances, although you still won’t be able to perform other operations (such as STBuffer) on them.

The new MakeValid method can “fix” an invalid spatial instance and make it valid. Of course, the shape will shift slightly, and there are no guarantees on the accuracy or precision of the changes made. The code in Listing 10-27 uses MakeValid to remove overlapping parts (which can be caused by anomalies such as inaccurate GPS traces), effectively converting the invalid line string into a valid spatial instance.

DECLARE @line geometry = 'LINESTRING(1 1, 2 2, 3 2, 2 2)'
SELECT @line.MakeValid().ToString() AS Fixed

The WKT string returned by the SELECT statement shows the “fixed” line string:

Fixed
----------------------------------------------------------------
LINESTRING (3 2, 2 2, 1.0000000000000071 1.0000000000000036)

Other Enhancements

The remainder of this post gives brief mention to several other noteworthy spatial enhancements added in SQL Server 2012. These include better geography support, and precision and optimization improvements.

Support for geography Instances Exceeding a Logical Hemisphere

Previous versions of SQL Server supported geography objects as large as (slightly less than) a logical hemisphere (half the globe). This limitation has been removed in SQL Server 2012, which now supports geography instances of any size (even the entire planet).

When you define a geography polygon, the order in which you specify the ring’s latitude and longitude coordinates (known as vertex order) is significant (unlike geometry, where vertex order is insignificant). The coordinate points are always defined according to the left-foot inside rule; when you “walk” the boundary of the polygon, your left foot is on the inside. Thus, vertex order determines whether you are defining a small piece of the globe, relative to the larger piece defined by the entire globe except for the small piece (that is, the rest of the globe).

Since previous versions of SQL Server were limited to half the globe, it was impossible to specify the points of a polygon in the “wrong order,” simply because doing so resulted in too large a shape (and thus, raised an error). That error potential no longer exists in SQL Server 2012, so it’s even more critical to make sure your vertex order is correct, or you’ll be unwittingly working with the exact “opposite” shape.

If you have a geography instance that is known have the wrong vertex order, you can repair it using the new ReorientObject method. This method operates only on polygons (it has no effect on points, line strings, or curves), and can be used to correct the ring orientation (vertex order) of the polygon. The following code demonstrates.

-- Small (less than a logical hemisphere) polygon
SELECT geography::Parse(
 'POLYGON((-10 -10, 10 -10, 10 10, -10 10, -10 -10))')

-- Reorder in the opposite direction for "rest of the globe"
SELECT geography::Parse(
 'POLYGON((-10 -10, -10 10, 10 10, 10 -10, -10 -10))')

-- Reorient back to the small polygon
SELECT geography::Parse(
 'POLYGON((-10 -10, -10 10, 10 10, 10 -10, -10 -10))').ReorientObject()

Three geography polygon instances are defined in this code. The first geography instance defines a very small polygon. The second instance uses the exact same coordinates, but because the vertex order reversed, it defines an enormous polygon whose area represents the entire globe except for the small polygon. As explained, such a definition would cause an error in previous versions of SQL Server, but is now accommodated without a problem by SQL Server 2012. The third instance reverses the vertex order on the same shape as the second instance, thereby producing the same small polygon as the first instance.

Full Globe Support

Along with the aforementioned support for geography instances to exceed a single logical hemisphere comes a new spatial data class called FULLGLOBE. As you may have guessed, this is a shape that represents the entire planet. If you’ve ever wondered how many square meters there are in the entire world, the following query gives you the answer (which is 510,065,621,710,996 square meters, so you can stop wondering).

-- Construct a new FullGlobe object (a WGS84 ellipsoid)
DECLARE @Earth geography = 'FULLGLOBE'

-- Calculate the area of the earth
SELECT PlanetArea = @Earth.STArea()

All of the common spatial methods work as expected on a full globe object. So you could, for example, “cut away” at the globe by invoking the STDifference and STSymDifference method against it using other polygons as cookie-cutter shapes.

New “Unit Sphere” Spatial Reference ID

The default spatial reference ID (SRID) in SQL Server 2012 is 4326, which uses the metric system as its unit of measurement. This SRID also represents the true ellipsoidal sphere shape of the earth. While this representation is most accurate, it’s also more complex to calculate precise ellipsoidal mathematics. SQL Server 2012 offers a compromise in speed and accuracy, by adding a new spatial reference id (SRID), 104001, which uses a sphere of radius 1 to represent a perfectly round earth.

You can create geography instances with SRID 104001 when you don’t require the greatest accuracy. The STDistance, STLength, and ShortestLineTo methods are optimized to run faster on the unit sphere, since it takes a relatively simple formula to compute measures against a perfectly round sphere (compared to an ellipsoidal sphere).

Better Precision

Internal spatial calculations in SQL Server 2012 are now performed with 48 bits of precision, compared to 27 bits used in SQL Server 2008 and SQL Server 2008 R2. This can reduce the error caused by rounding of floating point coordinates for original vertex points by the internal computation.

Summary

This blog post introduced you to some of the powerful new spatial capabilities added to SQL Server 2012. You saw how to use STNumCurves and STCurveN to obtain curve information from circular data, the BufferWithCurves method to produce more efficient padded line shapes than STBuffer, and the ShortestLineTo method to figure out the shortest distance between two shapes. Then you saw how to use the new MinDbCompatibilityLevel, STCurveToLine, and CurveToLineWithTolerance methods for supporting backward compatibility with SQL Server 2008. You also learned how SQL Server 2012 is much better at handling invalid spatial data, using the STIsValid, IsValidDetailed, and MakeValid methods. Finally, you learned about the new full globe support, unit sphere SRID, and improved precision.

You can learn much more about spatial functionality in Tallan’s new book Programming Microsoft SQL Server 2012, which has an entire chapter dedicated to the topic. I hope you get to enjoy these powerful new spatial capabilities in SQL Server 2012!

Circular Strings

A circular string defines a basic curved line, similar to how a line string defines a straight line. It takes a minimum of three coordinates to define a circular string; the first and third coordinates define the end points of the line, and the second coordinate (the “anchor” point, which lies somewhere between the end points) determines the arc of the line. Here is the shape represented by CIRCULARSTRING(0 1, .25 0, 0 -1):

The following code produces four circular strings. All of them have the same start and end points, but different anchor points. The lines are buffered slightly to make them easier to see in the spatial viewer.

-- Create a "straight" circular line
SELECT geometry::Parse('CIRCULARSTRING(0 8, 4 0, 8 -8)').STBuffer(.1)
UNION ALL  -- Curve it
SELECT geometry::Parse('CIRCULARSTRING(0 8, 4 4, 8 -8)').STBuffer(.1)
UNION ALL  -- Curve it some more
SELECT geometry::Parse('CIRCULARSTRING(0 8, 4 6, 8 -8)').STBuffer(.1)
UNION ALL  -- Curve it in the other direction
SELECT geometry::Parse('CIRCULARSTRING(0 8, 4 -6, 8 -8)').STBuffer(.1)

The spatial viewer in SQL Server Management Studio shows the generated shapes:

The first shape is a “straight circular” line, because the anchor point is position directly between the start and end points. The next two shapes use the same end points with the anchor out to the right (4), one a bit further than the other (6). The last shape also uses the same end points, but specifies an anchor point that curves the line to the left rather than the right (-6).

You can extend circular strings with as many curve segments as you want. Do this by defining another two coordinates for each additional segment. The last point of the previous curve serves as the first end point of the next curve segment, so the two additional coordinates respectively specify the next segment’s anchor and second end point. Thus, valid circular strings will always have an odd number of points. You can extend a circular string indefinitely to form curves and arcs of any kind.

It’s easy to form a perfect circle by connecting two semi-circle segments. For example, the following illustration shows the circle produced by CIRCULARSTRING(0 4, 4 0, 8 4, 4 8, 0 4).

This particular example connects the end of the second segment to the beginning of the first segment to form a closed shape. Note that this is certainly not required of circular strings (or line strings), and that closing the shape by connecting the last segment to the first still does not result in a polygon, which is a two dimensional shape that has area. Despite being closed, this circle is still considered a one-dimensional shape with no area. As you’ll soon see, the curve polygon can be used to convert closed line shapes into true polygons.

Compound Curves

A compound curve is a set of circular strings, or circular strings combined with line strings, that form a desired curved shape. The end point of each element in the collection must match the starting point of the following element, so that compound curves are defined in a “connect-the-dots” fashion. The following code produces a compound curve and compares it with the equivalent geometry collection shape.

-- Compound curve
 DECLARE @CC geometry = '
  COMPOUNDCURVE(
   (4 4, 4 8),
   CIRCULARSTRING(4 8, 6 10, 8 8),
   (8 8, 8 4),
   CIRCULARSTRING(8 4, 2 3, 4 4)
  )'

-- Equivalent geometry collection
 DECLARE @GC geometry = '
  GEOMETRYCOLLECTION(
   LINESTRING(4 4, 4 8),
   CIRCULARSTRING(4 8, 6 10, 8 8),
   LINESTRING(8 8, 8 4),
   CIRCULARSTRING(8 4, 2 3, 4 4)
  )'

-- They both render the same shape in the spatial viewer
 SELECT @CC.STBuffer(.5)
 UNION ALL
 SELECT @GC.STBuffer(1.5)

This code creates a keyhole shape using a compound curve, and also creates an identical shape as a geometry collection (though notice that the LINESTRING keyword is not—and cannot—be specified when defining a compound curve). It then buffers both of them with different padding, so that the spatial viewer clearly shows the two identical shapes on top of one another, as shown:

Both the compound curve and the geometry collection yield identical shapes. In fact, the expression @CC.STEquals(@GC) which compares the two instances for equality returns 1 (for true). The STEquals method tests for “spatial equality,” meaning it returns true if two instances produce the same shape even if they are being rendered using different spatial data classes. Furthermore, recall that segments of a circular string can be made perfectly straight by positioning the anchor directly between the end points, meaning that the circular string offers yet a third option for producing the very same shape. So which one should you use? Comparing these spatial data classes will help you determine which one is best to use in different scenarios.

A geometry collection (which was already supported in SQL Server 2008) is the most accommodating, but carries the most storage overhead. Geometry collections can hold instances of any spatial data class, and the instances don’t need to be connected to (or intersected with) each other in any way. The collection simply holds a bunch of different shapes as a set, which in this example just happens to be several line strings and circular strings connected at their start and end points.

In contrast, the new compound curve class in SQL Server 2012 has the most constraints but is the most lightweight in terms of storage. It can only contain line strings or circular strings, and each segment’s start point must be connected to the previous segment’s end point (although it is most certainly not necessary to connect the first and last segments to form a closed shape as in this example). The DATALENGTH function shows the difference in storage requirements; DATALENGTH(@CC) returns 152 and DATALENGTH(@GC) returns 243. In our current example, DATALENGTH(@CC) returns 152 and DATALENGTH(@GC) returns 243. This means that the same shape requires 38% less storage space by using a compound curve instead of a geometry collection. A compound curve is also more storage-efficient than a multi-segment circular line string when straight lines are involved. This is because there is overhead for the mere potential of a curve, since the anchor point requires storage even when it’s position produces straight lines, whereas compound curves are optimized specifically to connect circular strings and (always straight) line strings.

Curve Polygons

A curve polygon is very similar to an ordinary polygon; like an ordinary polygon, a curve polygon specifies a “ring” that defines a closed shape, and can also specify additional inner rings to define “holes” inside the shape. The only fundamental difference between a polygon and a curve polygon is that the rings of a curve polygon can include circular shapes, whereas an ordinary polygon is composed exclusively with straight lines. Specifically, each ring in a curve polygon can consist of any combination of line strings, circular strings, and compound curves that collectively define the closed shape. For example, the following code produces a curve polygon with the same keyhole outline that I just demonstrated for the compound curve.

-- Curve polygon
 SELECT geometry::Parse('
  CURVEPOLYGON(
   COMPOUNDCURVE(
    (4 4, 4 8),
    CIRCULARSTRING(4 8, 6 10, 8 8),
    (8 8, 8 4),
    CIRCULARSTRING(8 4, 2 3, 4 4)
   )
  )')

This code has simply specified the same compound curve as the closed shape of a curve polygon. Although the shape is the same, the curve polygon is a two-dimensional object, whereas the compound curve version of the same shape is a one-dimensional object. This can be seen visually by the spatial viewer results, which shades the interior of the curve polygon as shown here:

Conclusion

Circular data support is an important new capability added to the spatial support in SQL Server 2012. In this blog post, I demonstrated the three new spatial data classes for curves and arcs: circular strings, compound curves, and curve polygons. Stay tuned for my next post (coming soon), for more powerful and fun spatial enhancements coming soon in SQL Server 2012!

The first option is to have the part itself would write the script tag. This allows the part to operate as a “black box” – just drop it in and it works – But it means that there will be script tags loading file scattered throughout the page, and that the part needs to know your folder structure where you keep your JavaScript files. And it needs to know if you want the file loaded from you website or from a CDS like Googleapi.com. And, since there’s a good chance it will depend on jQuery, you have to make sure that jquery.js is loaded first, at the top of the page, despite “best Practices” which say script files should be loaded at the bottom of the page. Then, let’s say, two different partial views on the same page use the same JS file, you need a way of making sure it’s only included once. Plus, there’s a good chance it will also depend on its own CSS file being loaded, which doubles the problems above. Microsoft (well, PluralSite’s training videos on Microsoft’s site) recommends putting the script tags in a @section named Scripts, and rendering that in the layout, which helps but only addresses some of the problems)

Alternately, you can break the black box, and manually add the needed script & CSS link tags in your layout. This allows you to group the files tag together in the proper places, CSS at the top, JS at the bottom. But, you must know all the JS files all component of the page need, including all dependencies they have. And if you are putting these in a layout file, then you’ll need to put all the JS files needed for all pages anywhere on the site.

Wouldn’t it be great if there was a way to automatically figure out just the files we need for a certain page, and include just those, without us having to do a lot of thinking about it. Isn’t that the type of thing we invented computers for?

Monorail also lacked such a manager, but Monorail has neither the major corporate sponsor nor the large user community base of ASP.NET MVC, where I figured someone would have written one. I wrote a manager like this for Monorail, so I guess that someone is going to be me… which leads us to the JavascriptHelper.

Goals:

My goals for the JavascriptHelper were the following:

• To have all needed JS files grouped together, in a single spot I specify (presumably at the bottom of the layout)
• To be able to specify a needed JS file in a view, partial view, or helper.
• To have all JS files that file depends on included automatically
• To have files included only once, regardless of how many pieces requested them.
• To be able to specify a block of JS code in a view, partial view or helper and have all the code blocks bundled together.
• To be able to say if a code block should be included one per page, or repeatedly.
• To be able to associate a needed CSS file, and have it similarly included where I specify in the layout.
• To be able to specific a needed file by a simple name.
• To be able to easily update the file a particular name refers to (in case where the actual filename includes the version number, like jquery-1.5.1.js
• To be able to use one version of a file during development/debugging and easily switch to another (presumably mini-ified) for production.
• To be able to use a local version of a file during development/debugging (when I’m often off-line), and easily switch to Google’s CDS for production.
• To be able to gather a collection a JS files into a single, combined file (mini-fied on the fly) (OK, the JavascriptHelper doesn’t actually do that, but implementing it would require rewriting only one method — and adding a controller that handles the actual bundling & mini-fying. We’ll get to that eventually)

Usage

Let’s say for example that I have a partial view that uses the jQuery UI slider control (which I’ll specify some unique id value). Plus it has JS code which needs to be called to initialize it. Say this is in the form of a method and a call to that method using that id. Now, let’s say that we want several sliders on that page, and use that partial view several times, so we’ll only the UI scripts and the method definition once, but we’ll need each separate call to the function. To handle this, you’d need to add to you partial view, the following:

Script.Std("slider")

Script.AddScript("MySlider",
"function HideSlider(id) { $(id).Hide();}")

Script.AddScript("HideSlider(‘#"+ myId + "’);")

“Script.Std()” says that “slider” is one of the standard JavaScript files which we have defined what it’s traits and dependencies are. Actually, that could be a comma-separated list of them, so you state everything you need in one line. I originally envisioned only a few “standard” file – jQuery, jQuery UI, et al – but soon realized assigning a keyword for every script file used made life easier. In fact, it will even accept “self” to load a script & CSS file based on the name of the view, i.e., id Script.Std(“self”) is used in /Home/Index, then it will load /Scripts/Views/Home/Index.js and /Content/Css/Home/index.css (if they exist on the file system). How a file is pre-defined, as well as where we get a Script object, will be discussed in the next section.

The first “Script.AddScript()” call defines the function that we need. The second AddScript called calls that function, using the id specific to that instance of the partial view. So, if our page has three instances of this partial view, we’ll need the function definition only once, but the call to it three times. This is handled by given a name to the snippet that need not be repeated. All blocks with the same name are rendered only once (actually, block with the same name as an existing block are ignored, so make sure that you only use a particular name for one script block. )

Then in the Layout, we just add the lines:

<html>
<head>
@Script.InsertCss();
</head>
<body>

/* other content for the page */

@Script.InsertScripts();
</body>
<html>

This will produce an output of :

<Html>
<head>
<link rel="stylesheet" type="text/css" href="/content/css/ui.base.css" />
<link rel="stylesheet" type="text/css" href="/content/css/ui.core.css" />
<link rel="stylesheet" type="text/css" href="/content/css/ui.slider.css" />
</head>
<body>
/* other content for the page */
<script type="text/javascript" src="/Scripts/jquery-1.6.1.min.js"></script>
<script type="text/javascript" src="/Scripts/ui/jquery.ui.core.js"></script>
<script type="text/javascript" src="/Scripts/ui/jquery.ui.widget.js"></script>
<script type="text/javascript" src="/Scripts/ui/jquery.ui.mouse.js"></script>
<script type="text/javascript" src="/Scripts/ui/jquery.ui.slider.js"></script>
<script type="text/javascript">
//<![CDATA[
function HideSlider(id) { $(id).Hide();}
HideSlider('#sl12321');
HideSlider('#sl14315');
HideSlider('#sl68953');
//]]>
</script></body>
<html>

Setup:

Creating a Script object.

The “Script” object needs to be created differently depending on where it is being used. (You can, of course, call it anything you like. I use “Script” with a capital S, so that it corresponds to @Html).

When used in a view, create it like this:

@{ var Script = StateTheaterMvc.Component.JavascriptHelper.Create(this); }

When used inside a @helper method or an HtmlHelper extension method:

var script = StateTheaterMvc.Component.JavascriptHelper.Create(WebPageContext.Current);

Configuration XML file

Finally, we reach the part which is at the heart of the JavascriptHelper, the jslibraries.xml file. It’s a bit complex, but the default I’ve set up is probably good enough, with perhaps only a few minor tweaks, and once fully configured to your taste, you could easily standardize on that for your whole enterprise. It is, however, simple enough that a NuGet package could be updated it when being added to a project. And the good news is that I’ve also create a XSD schema file for it, so you can have IntelliSense to help you along.

The root element is <libraries> and it has three optional attributes:

“localjspath=” which gives the relative location of the folder where you put your js files. The default is “~/Scripts” which is the ASP.NET MVC default.

“selfJsPath=” which gives the relative location of the folder under which you put your view-specific js files. They follow the same structure as view files, so if you request the js file for /Home/Index, the view file would be /Views/Home/Index.cshtml, and the js file used what be /Scripts/Views/Home/Index.js. Defaults to “~/Script/Views”

“useDebugScripts=” when set to “true” forces use of debug versions of js files when available. Defaults to false. Debug scripts are always used when a debugger is attached.

<library name="jquery" version="1.6.2" useGoogle="false"           pathname="jquery-1.6.1.min.js" debugPath="jquery-1.6.1.js" />

Within the <libraries> element, there are a collection of <library> elements – one for each standard javascript file you’ll be using– which have two required and several optional attributes:

“name=” which gives a unique name for a particular javascript file. It is required and is used by the helper and throughout the xml file to refer to that file.

“pathname=” which gives the path, relative to the localjspath described above, and filename of this file. This can also be a fully-qualified URL if it’s a remote file. It is required. (unless useGoogle

“debugPath=” which, like the pathname attribute, give the relative path to a javascript file to be used when debugging. This is optional and defaults to the value given for the pathname. The idea here is the you set the debugPath to the full, commented version, and the pathname to the mini-fied version, and the helper figures out which to use.

“dependsOn” which is a list of comma separated name of file, which must be loaded before this one. This is the most powerful feature, but also the most confusing, so we’ll expand upon it in a moment. It is optional and defaults to no dependencies

“alias=” which is a list of comma separated alternate names this file could be identified as. I added this because I could never remember if it’s “accordion” or “accordian”. This is optional and defaults to no aliases.

“css=” which gives the name of the css element (see below) associated with this file.

“useGoogle=” which, when set to true, will generate a request to the googleapi.com CDN to load the file. Optional, defaults to false. If true, “version” attribute is required.

“version=” is used only when “useGoogle” is true. Gives the version of the file to load from Google.

Also with the <libraries> element (at the same level as the <library> elements), there is the <css> group.

The <css> element has only one attribute:

“localcsspaath” which gives the relative location of the folder where you put your CSS files. The default is “~/Content” which is the ASP.NET MVC default.

Within the <css> element are multiple <sheet> element, one for each css file associated with a js file. They have two required attributes:

“name=” Unique name used to identified the particular css file. Matches name given in the “css” attribute in the <library> element above. Can be the same as the name used for the js file in the <library> element.

“pathname=” which gives the path, relative to the localcsspath described above, and filename of this file.

Example:

<library name="jquery" version="1.6.1" useGoogle="false" pathname="jquery-1.6.1.min.js"
     debugPath="jquery-1.6.1.js" />
<library name="uicore" dependsOn="jquery" pathname="ui/jquery.ui.core.js"/>
<library name="uiwidget" dependsOn="uicore" pathname="ui/jquery.ui.widget.js"/>
<library name="mouse" dependsOn="uiwidget" pathname="ui/jquery.ui.mouse.js"/>
<library name="datepicker" dependsOn="uiwidget"
    pathname="ui/jquery.ui.datepicker.js" css="ui" />
<library name="slider" dependsOn="uiwidget,mouse"
    pathname="ui/jquery.ui.slider.js" css="ui" />

Starting with the first element, we specified a JavaScript file, which we’ll be calling “jquery”.   When we ask for “jquery”, we’ll normally get “jquery-1.6.1.min.js” , unless we’re debugging, in which case, it will load “jquery-1.6.1.js”.  It will load these from the website, but, if, as I put it into production, I flip the useGoogle file to true, then it will load it from http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.js 

(Note that the “name” value is used to the URL here.  This is the only place where the actual name used is significant.  Otherwise it can just be any unique string.  This is wrong, and will be fixed in some future release).

Next we want to define the complete componentized version of jQuery UI, so that we can load just the parts we want. First, we declare the UI core as depending on jQuery.  Then we declare widget component as depending on the core.  And the mouse component as depending on the widgets.

Then we can the individual components themselves.  “datepicker” as depending on the widgets; “slider” as depending on the widget & the mouse components.  Since the mouse already depends on widget, it was really necessary to specify both here, but there’s no harm.  So, if you request to use “slider” on your page, then the helper makes sure that jQuery, the UI core, UI Widgets, mouse & slider components are all included, in the proper order.  (Note, there is no checking for circular dependencies, so be careful how you specify the dependsOn attribute)

Both are also associated with the “ui” css file, which brings us to that section:

<css localcsspath="~/content/css/Views">   <sheet name="ui" pathname="ui/themes/Redmond/jquery-ui-1.8.13.custom.css" />   <sheet name="cluetip" pathname="jquery.cluetip.css" />

Both of the jQuery UI components above give “ui” as their CSS file (the theme roller doesn’t create individual CSS files) so if either (or both) is used, that file is included.  CSS files don’t have a separate dependency tree, but all associated CSS files for every dependent js file up the tree are included, so if you wanted to use the separate jQuery UI CSS files, you’d associate  “ui.core.css” with uicode”, “ui.base.css” with “uiwidget” and each component with its own CSS file, and all the needed files will be included.

API

The API is fairly simple:

Std(string) – accepts a comma-separated list of script file ids.

AddScript(string id, string script) – accepts a block of script as text. Multiple calls with the same id are rendered only once.

AddScript(string script) – accepts a block of script as text. Each call is rendered.

All script from either AddScript methods is rendered in a block at the script insertion point.

AddOnReadyScript(string script) – accepts a block of script as text. Appended to script run on page ready. All on rendered, wrapped in a jQuery document ready event function, at the point of InsertOnReady()

InsertScripts() — Renders all script files & script blocks.

InsertOnReady() — Renders all script block intended for startup, wrapped in a jQuery on ready function.

InsertCss() — Renders all css files

What’s the next step?

Now that I’ve made this public, it’s really just a beta. I think there’s still a bit more to be done before it’s ready to be “Production-Ready v1.0”. And I need some feedback….

First of all, how exactly should it be packaged? I’ve been just added to source file to my project, which is simple, but not very elegant. The alternative would be to create an assembly for it, but it’s just one file, so that seem like overkill. I’d really like to create a NuGet package for this, but that question needs to be settled first.

Also, how is the API? Are the method names sufficiently intuitive?

Is an XML file the proper way to store the dependency information?

Is there any feature that really needs to be added?

The code:

The source code is available (under the Apache license) from my GitHub library:

http://github.com/jamescurran/JavascriptHelper

All .netTier objects inherit from a base class called EnitityBase which is what gives the ability crawl an object graph. Going through the following EntityCrawler class will give a better understanding of the importance of the EntityBase. Here is the code:

public class EntityCrawler
{
    private readonly List<EntityBase> _touchedEntities;
    private readonly Func<EntityBase, EntityBase> _processEntity;

    public EntityCrawler(Func<EntityBase, EntityBase> customProcess)
    {
        _touchedEntities = new List<EntityBase>();
        _processEntity = customProcess;
    }

    private static bool IsTypeEntityBase(Type t)
    {
        if (t != null)
        {
            return t == typeof(EntityBase) || IsTypeEntityBase(t.BaseType);
        }
        return false;
    }

    public EntityBase CrawlEntity(EntityBase entity)
    {
        if (entity != null && !_touchedEntities.Contains(entity))
        {
            _touchedEntities.Add(entity);

            var entityProperties = entity.GetType().GetProperties().Where(pi =>
                IsTypeEntityBase(pi.PropertyType)
            );

            foreach (var subEntity in entityProperties)
            {
                CrawlEntity((EntityBase)subEntity.GetValue(entity,null));
            }

            var collectionProperties = entity.GetType().GetProperties().Where(pi =>
                pi.PropertyType.IsGenericType
                && pi.PropertyType.GetGenericTypeDefinition() == typeof (TList<>)
                && IsTypeEntityBase(pi.PropertyType.GetGenericArguments()[0])
            );
            foreach (var collectionProperty in collectionProperties)
            {
                foreach (var subEntity in (IList)collectionProperty.GetValue(entity, null))
                {
                    CrawlEntity((EntityBase)subEntity);
                }
            }
            entity = _processEntity(entity);
        }
        return entity;
    }
}

Code Walk-Through

Two private class variables (lines 3-4) : _touchedEntities is a list of EntityBases on the object graph that have been hit by the process. Since there may be points in an object graph where you have a circular relationship, it is very important to check that you have already been to that object otherwise you may end up crawling the graph forever.  _processEntity is a function that takes in and EntityBase and spits out an EntityBase.  This is function is what is performed on each entity in the graph and needs to be provided to the constructor.

Constructor (lines 6-10) : Sets the above variables.

IsTypeEntityBase Method (lines 12-19) : Recursively drills through Type t to find if any of its base types are of type entity base.

CrawlEntity Method (lines 21-51) :

1. Starts off making sure the entity is not null and that it has not been touched yet. If these conditions are true, the entity is added to _touchedEntities and then a list named entityProperties is populated.  EntityProperties contains all the subproperties of type EnityBase on the current entity.  CrawlEntity is then recursively called on each of these entities.
2. Next a list of named collectionProperties is populated which contains all the sub-properties of the current entity which are of type TList<EntityBase>.  One thing to note, on the last condition “IsTypeEntityBase(pi.PropertyType.GetGenericArguments()[0])”, we know that there is one generic argument because we already know the type is TList<> from the condition before.  Once the collectionProperties are populated, we iterate over each collection and recursively call CrawlEntity on each EntityBase of that collection.
3. Lastly we call whatever process declared in the constructor on the entity base.

Quick Example

The following code shows a VERY basic example of using the Entity Crawler.  It goes through the entire entity graph and prints each Type and TrackingKey (a pipe separated string containing the primary key for table the entity models and that key’s value) of each entity that has been changed since it was loaded from the database.  This example grabs Product 707 from the Microsoft Adventure Works database (with .netTiers built on top of it), changes a few things on the object and then checks for the changes by crawling the entity.  The function passed into the EntityCrawler also changes the color of any EntityBase of type Product.

private void runMe()
{
    var provider = new SqlProductProvider(CONN_STRING, false, null);
    var product = provider.GetByProductId(707);
    provider.DeepLoad(product,true);

    product.ProductModelIdSource.CatalogDescription = "DESCRIPTION";

    Console.WriteLine(string.Format("The Color before : {0}", product.Color));
    var ec = new EntityCrawler(CheckForChanges);
    ec.CrawlEntity(product);
    Console.WriteLine(string.Format("The Color after : {0}", product.Color));
}

public EntityBase CheckForChanges(EntityBase entity)
{
    if (entity.EntityState == EntityState.Changed)
        Console.WriteLine(string.Format("You changed something on a(n) {0} object with a trackingkey of {1}.",
            entity.GetType().Name, entity.EntityTrackingKey));
    if (entity.GetType() == typeof(Product))
        ((Product) entity).Color = "CHANGED_COLOR";
    return entity;
}

Output:

The Color before : Red
You changed something on a(n) ProductModel object with a trackingkey of ProductModel|33.
The Color after : CHANGED_COLOR

Conclusion

Obviously there is much more you can do than what is exemplified above.  As long as the function you pass into the constructor takes in an EntityBase and spits out an EntityBase it’s fair game.  The main value you will get out of this is to perform actions on or query the data in the target EntityBase that may have been changed since the last time you retrieved a copy of it from your database.

There’s a great blog post to get you started with getting a Jetty instance on the cloud that I want to refer you to: http://blogs.msdn.com/b/dachou/archive/2010/03/21/run-java-with-jetty-in-windows-azure.aspx

Next download a sample spring application.  I was able to get one at: https://src.springframework.org/svn/spring-samples/petclinic/trunk/

The presence of a pom.xml file in the root directory tells us that the project can built using maven.  Install maven if you don’t have it, and then run an mvn clean install from the root directory.  That command will run all unit tests and build the solution.

If I recall, I had a little bit of difficulty with a couple of the tests.  I was able to comment out the failing tests, and the sample application ran fine for our purposes.  Once you get the spring application built, copy the *.war file to the web app dir of your jetty instance.  Startup your jetty instance locally and confirm that the spring app is working.

If the spring application works locally, the next step is to move it to the cloud

Rename your *.war to test.war so that it matches the war from the blog above.  Overwrite the war from above with your new war containing the spring application.  The hardest part about getting a spring application to load instead of just the jetty splash page from the original tutorial is getting your JSP jars in place.  To acquire the JSP jars that were needed I downloaded Jetty 7.4.5.v20110725, and copied the jetty jsp folder (jetty-distribution-7.4.5.v20110725\lib\jsp) to JettyWorkerRole\app\jetty7\lib\jsp and with that your spring application is ready to be deployed to the cloud.

I had a lot of problems putting this tutorial together and generally wouldn’t recommend a java application on an Azure cloud.  There was tremendous difficulty debugging, because you can’t access the console that was started by the worker role.  When issues arise, I would just get blank screens in my web browser, and I had to assume (correctly, though I didn’t know it at the time) the issue was related to jsp jars missing.

When deploying reports to an SSRS server, the server creates a record in the Catalog table.  this table holds the report location, the binary data for the report, as well as parameter and property information, among other things.  On deployment, various report properties are extracted and added to the Properties column of the Categories table in the ReportServer database.  A sample is displayed below:

   1: <Properties>

   2:   <Language>en-US</Language>

   3:   <HasUserProfileQueryDependencies>False</HasUserProfileQueryDependencies>

   4:   <HasUserProfileReportDependencies>False</HasUserProfileReportDependencies>

   5:   <PageHeight>215.9</PageHeight>

   6:   <PageWidth>355.6</PageWidth>

   7:   <TopMargin>0</TopMargin>

   8:   <BottomMargin>0</BottomMargin>

   9:   <LeftMargin>0</LeftMargin>

  10:   <RightMargin>0</RightMargin>

  11: </Properties>

SSRS appears to use the data stored in the Properties column to detect paper size and orientation when printing the report.

Linked Reports

When creating a linked report, a new row is created in the Categories table, with the LinkSourceId column set to the Id column of the original report you’re linking from.  The Properties column is initialized with the following:

   1: <Properties/>

For some unknown reason, SSRS does not copy over the Properties data.  When printing a linked report, SSRS uses the Properties data from the linked report.  Since there is no property data, it uses defaults, generally 8.5×11. 

Solutions

Unfortunately, there is no facility in the Report Manager to directly set there properties, so one of the following needs to occur:

Solution 1: Setting Report Properties Through the ReportService.asmx Web Service

A post on Brian Weckler’s blog provides VB.NET code for connecting to the ReportService.asmx service and manually setting the properties:

http://blogs.msdn.com/b/bwelcker/archive/2005/09/07/461758.aspx

Solution 2: Updating the Linked Report Record in the Database

The property field can be directly updated in the catalog table.

   1: use ReportServer

   2:  

   3: declare @property varchar(max)

   4: declare @id uniqueidentifier

   5: select 

   6:     @id = ItemID,

   7:     @property = property

   8: from

   9:     [Catalog]

  10: where

  11:     Path = '/PathTo/MyReport'

  12:  

  13: update [Catalog]

  14: set 

  15:     property = @property

  16: where

  17:     LinkSourceId = @id

If anyone has any better solutions, please let me know!

Alternatively, you can turn to one of the two later technologies that Microsoft has built on top of WCF. These are WCF Data Services and WCF RIA Services, and they represent two very different approaches for building data-oriented services. Both provide abstractions that shield you from many underlying WCF particulars, so you get to spend more time focusing on your application and less time on plumbing. For one thing, you don’t need to code WCF contracts or manage change tracking on the client; all that gets done for you. With WCF RIA Services (and Silverlight), you don’t even need to create and update service references; Visual Studio generates code automatically via a special link that keeps your client and WCF RIA Services projects in sync at all times.

Both WCF Data Services and WCF RIA Services can solve many of the same problems, so it is only natural to question which one to use. The answer extends a bit beyond the standard “it depends on your scenario” response, since WCF RIA Services offers a lot more than just data access functionality. It also features client-side self-tracking entities, client-side validation, automatic server-to-client code generation, and more. In this blog post, I’ll discuss both platforms at a high level to help guide you in making the right choice.

WCF Data Services

Microsoft designed WCF Data Services as a thin layer over Entity Framework that exposes data-centric services to client applications. Out of the box, you can quickly build WCF Data Services over an Entity Data Model with virtually no effort. Custom providers for WCF Data Services for data sources other than Entity Framework are available; however, considerable additional effort is required to implement them. You can think of WCF Data Services as universal Web Services built just for data, although it can be easily extended with custom service operation methods. The platform is based on the industry standards of Representational State Transfer (REST) and the Open Data Protocol (OData), which means that these services are consumable by virtually every type of client in the world.

REST provides a uniform interface for querying and updating data. It is based on HTTP, meaning that client requests are issued in the form of GET, POST, MERGE, and DELETE actions — standard verbs understood by all HTTP clients. Any REST query can be invoked with an HTTP GET request by expressing all the elements of the query in a properly formed Uniform Resource Identifier (a URI, which is a more general term than Uniform Resource Locator [URL]). You can even test the service with an ordinary browser; simply type the properly formed URI directly into the address bar and you will receive the Atom Publishing Protocol (AtomPub) response (an XML dialect very similar to the Really Simply Syndication [RSS] feed format). The POST, MERGE, and DELETE verbs correspond respectively to insert, update, and delete operations supported by the service, and the payload (parameters, data, and other metadata) for these operations is passed in HTTP headers.

Just as REST enables universal data access via HTTP, the Open Data Protocol (OData) establishes universal data structure via standard serialization formats (see http://www.odata.org). All clients can handle plain text formats such as JavaScript Object Notation (JSON) and of course XML, and so OData defines standard response formats based on both formats. JSON provides a compact structure suitable for many basic types of services, while XML forms the basis for the more verbose AtomPub feed format. AtomPub is the default serialization format in WCF Data Services, because it effectively leverages the hierarchical nature of XML to describe the rich structure of data and metadata in an Entity Data Model.

The WCF Data Services client libraries for Windows/WPF, ASP.NET, Silverlight, and Windows Phone 7 include a special LINQ provider, commonly known as LINQ to REST. This provider automatically translates client-side LINQ queries into an equivalent OData URI, meaning that you don’t need to learn the OData URI syntax if you are building Microsoft clients over WCF Data Services (just use good old LINQ). The client libraries automatically deserialize the AtomPub feed response from WCF Data Services into ready-to-use objects. They also provide a stateful context object that can track changes on the client for pushing updates back to the server, although your code needs to explicitly notify the context about objects as they are changed.

WCF RIA Services

WCF RIA Services is, well, richer than WCF Data Services (and also newer). Indeed, the R in RIA means rich, although the full TLA (Three-Letter Acronym) can stand for Rich Internet Application or Rich Interactive Application—depending on who you’re talking to. Since its earliest days, WCF RIA Services was designed to work best with Silverlight, although it now also supports OData, SOAP, and JSON to reach a wider range of clients as well. You can build WCF RIA Services over any data access layer, including Entity Framework and LINQ to SQL. You can also use Plain Old CLR Objects (POCOs), in which case you handle the persistence yourself using your data access technique of choice, even conventional ADO.NET (raw readers and command objects, or DataSets). In any case, you expose WCF RIA Services by coding domain service classes that support CRUD operations, as well as other custom service operations. You also maintain a special metadata class for each entity that auto-magically surfaces on the client for effortless end-to-end validation across the wire.

When WCF RIA Services is used with Silverlight, you don’t need to create and update service references; Visual Studio generates code automatically via a special link that keeps your client and WCF RIA Services projects in sync at all times. Like a service reference, this link binds the two projects together, only a WCF RIA Services link couples them much more tightly than an ordinary service reference does. Public changes on the service side are reflected automatically in corresponding classes on the client side every time you perform a build, so you never need to worry about working against an outdated proxy in the client project simply because you forgot to manually update a service reference.

The WCF RIA Services link greatly simplifies the n-tier pattern, and makes traditional n-tier development feel more like the client/server experience. With the link established, Visual Studio continuously regenerates the client-side proxies to match the domain services on each build. It also auto-generates client-side copies of shared application logic you define in the services project, simply by looking for classes you’ve defined in files named *.shared.cs, or *.shared.vb. The link enforces automatic client-side validation and keeps validation rules in sync between the the domain services and the client at all times. Furthermore, client-side entities are completely self-tracking; you do not need to manually notify the context object of every change to every entity, as you are required to do with the WCF Data Services client library.

Comparing WCF Data Services and WCF RIA Services

The following table summarizes several key differences between the two platforms.

From this comparison, it looks like WCF RIA Services is more attractive for Silverlight clients than non-Silverlight clients—regardless of which data access layer is used. Conversely, it shows that WCF Data Services is more appropriate for use with Entity Framework than it is with other data access layers—regardless of which client is used. But let’s examine things a bit in a bit more detail.

If your scenario uses EF on the back end and targets Silverlight on the front end, then you are in the best position. Both WCF frameworks pack a huge win over writing traditional WCF services “by hand.” Your decision at this point is based on whether you simply require services to provide data access (that is, you primarily need CRUD support), or if are seeking to leverage additional benefits. Another consideration is whether you are targeting Silverlight as the client exclusively or not.

Of the two, WCF Data Services is relatively lightweight, and requires almost no effort to get up and running. So it’s the better choice if you only need data access functionality in your services, particularly if you want to keep your service open to non-Silverlight clients as well. WCF RIA Services is more robust, and offers numerous additional features. This makes it a very compelling choice for the development of rich client applications. Although it began as a platform almost exclusively designed for Silverlight, support is steadily emerging for other client platforms via OData, SOAP, and JSON, as well as self-tracking entity libraries now available for jQuery. However, it requires the effort of creating domain service classes to support CRUD operations.

Finally, both frameworks are extensible, and both can be secured by traditional authentication and authorization techniques. They are also both capable of integrating with the ASP.NET Membership provider for role management and personalization.

What if you are using neither Silverlight nor Entity Framework? Well, then your work will be cut out for you whatever choice you make. With WCF Data Services, you will need to implement either the Reflection or Streaming provider, or write your own custom provider. And with WCF RIA Services, you will not get to fully enjoy all the benefits of the framework, but you will still need to write domain services and metadata classes. After careful consideration, you may well conclude that neither choice is appropriate, and decide instead to stick with tried and true WCF services, coding your own service contracts, data contracts, binding configurations, change tracking, validations, and so on.

Summary

Both WCF Data Services and WCF RIA Services can represent huge savings in development effort. Which one you choose (or whether indeed you choose to use either) depends a great deal on your data access layer of choice and the types of clients you intend to reach. This post tells you what you need to know to intelligently distinguish between them.

Tallan’s upcoming book, Programming Microsoft SQL Server 2012, has an entire chapter dedicated to this topic. Look forward to extensive coverage and code samples for complete data access solutions using both platforms. The release date is just a few short months away, so stay tuned!

Project Portal Problems

TFS 2010 ships with integration by default for WSS 3.0 for project portals, with the option to use SharePoint 2010, which we decided to go with.  While the process template comes with a WSS3.0 SharePoint .wsp, the developers had offered an updated version of the .wsp for SharePoint 2010, which was basically a retargeted version of the SharePoint 2007 features.  This resulted in project portals with the old SharePoint 2007 look and feel with a ton of visual issues and errors interspersed throughout.

Updated SharePoint 2010 .wsp for Scrum for Team System

After some searching, I found that someone had converted the supplied SharePoint 2010 .WSP and updated it to the new SharePoint 2010 look and feel while repairing all of the issues in the original.

It is available here: http://www.thecontrarycat.com/2011/07/scrum-for-team-system-v3-and-sharepoint-2010/

The screenshot below shows the results:

That said, each SQL Server release continues to advance itself in vitally significant ways. SQL Server 2008 (released August 6, 2008) added a host of new features to the relational engine—T-SQL enhancements, Change Data Capture (CDC), Transparent Data Encryption (TDE), SQL Audit, FILESTREAM—plus powerful BI capabilities with Excel PivotTables, charts, and CUBE formulas. SQL Server 2008 R2 (released April 21, 2010) was dubbed the “BI Refresh,” adding PowerPivot for Excel, Master Data Services, and StreamInsight, but offering nothing more than minor tweaks and fixes in the relational engine.

The newest release—SQL Server 2012—is set to officially launch on March 7, 2012, and like every new release, this version improves on all of the key “abilities” (availability, scalability, manageability, programmability, and so on). The chief reliability improvement is the new High Availability Disaster Recovery (HADR) alternative to database mirroring. HADR (also commonly known as “Always On”) utilizes multiple secondary servers in an “availability group” for scale-out read-only operations (rather than forcing them to sit idle, just waiting for a failover to occur). Multi-subnet failover clustering is another notable new manageability feature.

SQL Server 2012 adds many new features to the relational engine, most of which are covered in Tallan’s new book: Programming Microsoft SQL Server 2012 (soon to be published). There are powerful T-SQL extensions, most notably the windowing enhancements, 22 new T-SQL functions, improved error handling, server-side paging, sequence generators, and rich metadata discovery techniques. There are also remarkable improvements for unstructured data, such as the FileTable abstraction over FILESTREAM and the Windows file system API, full-text property searching, and Statistical Semantic Search. Spatial support gets a big boost as well, with support for circular data, full-globe support, increased performance, and greater parity between the geometry and geography data types. Contained databases simplify portability, and new “columnstore” technology drastically increases performance of huge OLAP cubes (with VertiPaq for PowerPivot and Analysis Services) and data warehouses (with similar optimizations implemented in the relational engine).

The aforementioned features are impressive, but still amount to little more than “additives” over an already established database platform. A new release needs more than just extra icing on the cake for customers to perceive an upgrade as compelling. To that end, Microsoft has invested heavily in BI with SQL Server 2012, and the effort shows. The BI portion of the stack has been expanded greatly, delivering key advances in “pervasive insight.” This includes major updates to the product’s analytics, data visualization (such as self-service reporting with Power View), and master data management capabilities, as well Data Quality Services (DQS), a brand new data quality engine. There is also a new Business Intelligence edition of the product that includes all of these capabilities without requiring a full Enterprise edition license. Finally, SQL Server Data Tools (SSDT) brings brand new database tooling inside Visual Studio 2010. SSDT provides a declarative, model-based design-time experience for developing databases while connected, offline, on-premise, or in the cloud.

Of course there are more new features; I’ve only mentioned the most notable ones in this post. Although the relational engine has been rock-solid for several releases, it continues to enjoy powerful enhancements, while the overall product continues to reinvent itself by expanding its stack of services, particularly in the Business Intelligence space.