What I Learned from PDC - Domain Technologies (continued)

Controller Model: All the commanding and navigation instructions are implemented at this level. Think of this layer as reacting to menu clicks, hyperlinks or changes of URL address. The controller is one of the central models in ASP.NET MVC (Model View Controller) and in a good implementation will defer many of the control logic decisions to the domain model. In ASP.NET MVC, the controller is used to return a view based on an action, and will typically consult the model to do so. In other applications the controller is not as pronounced, however there are usually classes that expose functions to act as command targets.

Talking Points: Exposing ICommand for Silverlight has simplified the implementation of a control pattern. Best examples using the controller pattern are FT59: ASP.NET MVC 2: Ninjas Still on Fire Black Belt Tips by Scott Hanselman, FT22: Microsoft ASP.NET MVC 2: The New Stuff by Stephen Walther, CL22: Advanced Topics for Building Large-Scale Applications with Microsoft Silverlight by John Papa and CL21: Building Amazing Business Applications with Microsoft Silverlight and Microsoft .NET RIA Services by Brad Abrams. None of these talks show you how to build a controller, but they all use an MVC pattern to build their application.

Data Proxy: The Data Proxy layer is a service oriented architecture (SOA) where the communication is with a data source. There is no limit to the data proxies in this layer. In fact there is no limit to the number services your domain can subscribe or publish to. Proxies can be generated automatically by querying metadata about the WCF service. Proxies are class based representations that model the WCF services API. The abstraction is so good, you are hardly aware that you are using a service on a remote server as you program. Proxies can be generated for anything that has a communication contract. The contract is typically expressed in metadata and there are tools for translating the metadata into code that implements the contract explicitly.

This layer is all about communication. The pictures above were taken from Yavor Georgiev’s talk: CL06: Networking and Web Services in Silverlight. The first picture shows the technology layers that .NET WCF provides. The programming model is built over a TCP/IP based protocol. The second picture shows the spectrum of communication applications. Yavor discusses the interaction between communication and different types of applications, from transactional data systems to multicast video systems. Generally speaking, WCF RIA services is the Microsoft technology of choice for building Silverlight rich clients and there are several talks showing this.

Talking Points: See FT12: ADO.NET Data Services: What’s new with the RESTful data services framework Pablo Castro’s client demo (at 44 min in). For an intro to RIA services: CL21: Building Amazing Business Applications with Microsoft Silverlight and Microsoft .NET RIA Services with Brad Abrams. You can tell from this talk the Microsoft is shaping this technology to create Line of Business CRUD applications. You can dive below the surface with CL07: Mastering Microsoft .NET RIA Services.

What I Learned from PDC - Domain Technologies

The domain is the brain or personality of the application and is usually built with the help of a Subject Matter Expert (SME).

I like to think of the domain as having the real knowledge of the application and the Client and Server components as providing input/output services. Think of the case where a text box control is doing input validation. The code in the control can be kept simple, it just needs to verify that the text typed in by the user conforms to a validation rule, and if it does not, display some type of message.

An implementation that binds the control to a text string might also execute validation logic in the On-Click code behind method. An implementation that binds the control to a property lets the code in the control stay generic, and keeps all the validation logic in the domain model where it can be easily maintained. This separation of concerns is the ‘S’ of the ‘SOLID’ design principle and you can learn about the other components (OLID) here.

When you create a domain model that uses the vocabulary of your SME, and solves problems using the processes the SME would use, then the rest of the application becomes easier to build. The Client and Server layers become tools to visualize your domain model or persist your domain model.

Domain Model: The Domain Model executes the formal business logic and should be the primary location for all the application state transition rules. Very few talks have time to develop a Domain Model, however if you watch talks that focus on language features, LINQ, Rx or parallel computing they are full of examples showing how domain modeling is becoming more declarative and less imperative. That is, software design is evolving into describing what you need the computer to do instead of traditionally telling the computer how to do it. .NET is evolving to merge dynamic, functional and object oriented programming models into the platform. The declarative slant in coding allows the .NET platform to make decisions about how to execute the code at runtime, to take advantage of system resources like multiple CPUs or resources in the Cloud.

Talking Points: Microsoft talks do not focus on the domain model at all. The only talk I found that fits the definition is Cl36: Deep Dive on Bing Maps Silverlight Control because it focuses on the domain of mapping, however the domain is so well defined it is delivered as a GUI control and a service. Instead look to the language features to help you model your domain: FT11: Future Directions for C# and Visual Basic. Developers should be aware of a new (or maybe very old if you know LISP) way of programming FT20: F# for Parallel and Asynchronous Programming , languages for Data Modeling FT34: Microsoft Project Code Name “M”: The Data and Modeling Language, Parallel Computing Platform: P09: Manycore and the Microsoft .NET Framework 4: A Match Made in Microsoft Visual Studio 2010 and Erik Meijer VTL04: Rx: Reactive Extensions for .NET. Rx technology was the language innovation of the show. Learn about Rx in 15 min here.

I will cover the Controller Model and Data Proxy in the next post.

What I Learned from PDC - Client Technologies

Client Technologies

There are many different client side technologies in the Microsoft ecosystem, and each has evolved to meet niche markets and end user needs, including video game, business apps, reports, and web page browsing. The defining technology of the client is probably how the view is rendered and the device’s ability to interact with that rendering.

View Rendering: Microsoft provides two different solutions for rendering a GUI: the thin client solution is HTML/JavaScript rendered inside a web browser, the rich client solution is XAML, which can be rendered in a web browser via a Silverlight plug-in, or as part of a thick client application using WPF. So XAML is dual purpose with the caveat that the end user must install the Silverlight plug-in (5 MB, 30 second, one time operation, just like Flash). Simple HTML has more range, because it runs in any browser, but when you start adding CSS and JQuery libraries (and other fancy things) you begin to limit yourself to a subset of browsers, IE7,IE8,Firefox,… again if you can control your target, this is not a problem. The Silverlight plug-in is designed to remove browser incompatibilities and create a UI that is “run anywhere” including Mac and Linux.

Talking Points: FT29: Microsoft AJAX Library, jQuery, and Microsoft Visual Studio 2010 Stephen Walther, shows how to build thin HTML clients with a new open source AJAX library, including 40 client controls, Open Source.

View Model: The purpose of a View Model is to shape your domain model to a view rendering technology. You must manage the interaction controls, events, value conversion, input validation, and general state of the GUI controls rendering using this model. In WPF/Silverlight, the View Model provides a site to bind the UI to the domain model. Sometimes perceived as additional work by programmers, the decoupling of the view from the domain model actually simplifies the implementation of the client GUI by providing a site for view logic that is independent of the domain. Some good examples are multi-lingual UI’s, currency conversion, hiding sections based on roles, and changing screen presentations based on task, expertise or device size. This separation also makes the application much more testable using an automated test suite.

Talking Points: Newly added ICommand support was the final step in making the view rendering and the view model truly independent and testable. Some Silverlight talks that discuss View Models are Cl19: Building Line of Business Applications with Microsoft Silverlight 4 and John Papa’s talk Cl22: Advanced Topics for Building Large-Scale Applications with Microsoft Silverlight

What I Learned from PDC - Service Oriented Architecture

Mapping Functionality into Abstract Software Components

Each of the presentations at PDC are designed to discuss some aspect of Microsoft’s packaged technology: ASP.NET, SQL Server, Silverlight, Entity Framework, LINQ & PLINQ, MVC, WPF, WCF Data service, Azure, … Windows 7. In every case, the presentations show code samples on how to use that technology, and in the process they casually introduce some abstract software architecture concept (View Models, Data Proxies, Domain Models…) to help illustrate the technology.

Application Depth

I have extracted the software concepts from all those talks and constructed an application depth stack that maps these functional requirements to software layers. These layers combine the “best practices” in software design from ASP.NET MVC, WPF & Silverlight applications and also include technologies that are common to all solutions like WCF Data Services, SQL Server and Entity Framework. The software component names are not official and the code boundaries between them in many cases are not precise, but they are useful in categorizing the Microsoft technologies that are used to construct and execute each layer.

Client, Domain and Server Models

I broke the sections up into Client, Domain, and Server. The Domain section can execute on the client or the server. When deployed as a thin client, the Domain logic is executed on the Server, but when deployed as a rich client the Domain executes on the Client and helps manage State. Server components are traditional data access services. Using data services is now Microsoft’s preferred way of connecting to data. Data services use simple web protocols to request and transport data even if you are consuming data on the same machine as the client. The service can be accessed just by passing a URL. Data access is provided using proxy service “wrappers” that provide an API by ingesting the META data about the service. These are the building blocks of a Service Oriented Architecture (SOA).

Best Practices? For My Purposes They Are!

I am not saying that each of these abstract software components need to physically exist in order for you to have a well designed or valid .NET application. Most CRUDS database solutions (Create, Read, Update, Delete, Search) are put together in a forms-over-data software architecture and do not implement all of these components. I am saying that during the design/development phase of a solution, I believe that the most developers should at least think about these functional areas, even if it is just to dismiss them as unnecessary.