Over the next few pages, we’ll quickly explore each of the solution components and why we selected them. We will start with a series of bullets that describe each technology and then describe their role in our solution. Later on in the book, we’ll provide more information about each component as we dive into building our sample solution.

LightSwitch is the newest member of the Visual Studio family of tools designed to help you write the next generation of data-centric business applications. Over the past 10 to 15 years, many of us have used a variety of tools to develop business applications on the Microsoft platform. Many of us know and are familiar with tools such as Access, Visual Basic, Classic ASP, WinForms, ASP.NET WebForms, Silverlight, WPF, or ASP.NET MVC. With each new tool came new patterns and practices, along with new data access technology and new user interface concepts for developers to master. In a few short years, we had to master datasets, data sources, LINQ to SQL, LINQ to entities, and developing ASMX and then WCF Web Services. All these handcoded layers result in tremendous cost and a “brittleness” in our solutions. The complexity of our code became a distraction from the solutions we sought to create.

Entering the post-PC era of connected devices and continuous services, Microsoft needed an ability to create a new class of applications. These applications leverage Microsoft’s scalable server technology either on-premise or in Windows Azure. Tooling was needed to remove the complexity and achieve rapid application development and inherent support for iterative development cycles. The proliferation of connected devices—from PCs and laptops to iPhones and tablets—demand multiple clients, each optimized for the appropriate user experience. Finally, the technology industry is in a time of transition, so the platform should be model-driven, focusing developers on defining the logic rather than the code in order to insulate us from technology change.

LightSwitch is designed around data and screens. The entire application experience is based around the logic built into your database model. As a user of LightSwitch, if a screen doesn’t come together in just a few minutes, it typically means that your database doesn’t correctly reflect your data. LightSwitch allows you to define the entities and their properties in a data designer. Visual Studio takes that information and generates, on your behalf, a SQL Server or SQL Azure database, an entity framework data layer, and OData WCF services.

Each of the entities we create in LightSwitch provides hooks that allow us to add our own code or logic where necessary, such as item creating, created, updating, updated, deleting, or deleted event handlers. We can also extend properties with validation rules using VB or C# code that will be built into our OData services.

OData is the Open Data Protocol based on ATOM (XML-based syndication format used for web feeds) and Representational State Transfer (REST) techniques. This protocol was created by Microsoft in partnership with SAP, IBM, and other industry partners. It’s currently under review by the Organization for the Advancement of Structured Information Standards (OASIS) as a broader standard. OData allows us to easily communicate between systems using web-based technologies and is key to new solutions.

The LightSwitch-generated clients perform all communication to the services on the server using the OData protocol. SharePoint lists provide a feed via the OData protocol. Reporting Services reports all have the ability to create an OData feed of the data behind the report. An Excel file stored in SharePoint 2013 can provide an OData feed of the data inside each worksheet. Finally, the Excel 2010 client with PowerPivot or the Excel 2013 client can natively consume and mash up multiple OData clients, letting us easily combine the data from our line of business applications, SharePoint data, and unstructured data stored in Excel files within SharePoint.

Let’s talk about clients. We’ve all heard the buzz about HTML5. In late 2010, Bob Muglia, who was leading the Microsoft Server and Tools Business Division at Microsoft, announced that their strategy had changed to focus on HTML5 for reach across devices rather than the company’s own Silverlight technology. Over the next two years, we learned that the XAML markup language behind Silverlight and WPF became a key part of the Windows 8 development toolset, which HTML5 and JavaScript moved into the foreground for cross-platform web applications. LightSwitch allows us to take advantage of technologies that are mature today, as well as new standards like HTML5 and JavaScript whose tooling are still evolving.

One of the great things about Visual Studio LightSwitch is that it’s designed for multiple clients. As shown in Figure 2-1, the LightSwitch-generated WCF Data Services provide an abstraction layer where our data access, business rules, and logic are reused across any client that can consume OData XML or JSON data.

Figure 2-1. LightSwitch Logical Architecture

What makes this story so compelling is that you’re not limited to the capabilities of LightSwitch or any other single development tool. LightSwitch creates a very compelling user interface in Silverlight, which means that you can create an application with multiple independent tabs—perfect for complex data entry. It’s a great tool for data-centric applications. The HTML companion applications are generated as a touch-centric single document interface using JQuery mobile controls. If neither of these out-of-the-box user experiences meets your needs, you can create your own by consuming the services either as JSON or as XML. The same services can be consumed directly from Excel or PowerPivot in order to provide some great reporting scenarios. Each data source in LightSwitch exposes a WCF Data Services endpoint.

Lastly, LightSwitch as a platform will continue to grow and evolve as Microsoft adds new auto-generated clients in the future. We captured some obvious examples with Windows 8 or Office clients, but the sky is the limit. As you can see in Figure 2-2, the LightSwitch solution supports having a single-server project with multiple clients. In this case, we are showing a server project, a traditional Silverlight client, and a mobile HTML companion application. It’s also easy to extend this by adding your own projects that consume the OData service. Good examples might be an ASP.NET MVC client, or a Windows service that provides you with asynchronous activities.

Figure 2-2. Multiple Clients in Visual Studio LightSwitch

As you will see below, LightSwitch is a whole lot more than rapid application development. Leveraging model-driven development concepts, LightSwitch delivers a service-oriented architecture that supports multiple clients and multiple data sources. LightSwitch is well suited to develop the next generation of data-centric business applications.

As you can see from Figure 2-3, SharePoint has a lot to offer our solution. For a few versions of the platform, some form of the wheel shown above has been used to organize and group the capabilities of SharePoint. SharePoint offers web content management features that make it easy for application owners to maintain information about the app, the process, help, and so on. SharePoint focuses on collaboration and information sharing, which can be great if you need to add a discussion list or a release blog to present new features of your solution. A lot of that SharePoint “goodness” forms the icing on the cake for our application.

Figure 2-3. Capabilities of SharePoint.

In our solution, we will leverage a Site to host our application and bring it all together. We will use the Content capability to add a list to our LightSwitch solution as the knowledge base for our help desk application. Search will make it easy for our users to find information from previous help desk requests, and we will deliver Insights using the business intelligence capabilities delivered by SharePoint when used in conjunction with SQL Server 2012. These include PowerPivot, Excel Services, Power View, and Reporting Services. In Part IV, we will go into detail about each of these clients and how they contribute to our overall solution.

SharePoint is another example of a platform that is undergoing a significant transformation. Architecturally, SharePoint is more or less just an ASP.NET application (see Figure 2-4). It began as a portal environment, and Web Parts were the widgets or “portlets” that were used to provide extensibility. With SharePoint 2007, Microsoft began using ASP.NET Web Parts directly in SharePoint, giving developers the ability to package and deploy this ASP.NET code onto the server using features and solution packages.

Figure 2-4. Full-trust solution architecture

Sandbox Solutions and CSOM: SharePoint 2010

In SharePoint 2010, two new capabilities were added to the platform to reduce the risk of SharePoint development. The first was new remote application programming interfaces. SharePoint 2010 introduced the Client Side Object Model (CSOM) which provides capabilities for JavaScript and managed code (.NET/Silverlight) clients to interact with the SharePoint object model. CSOM is optimized for remote invocation and provides the ability to batch execute commands to reduce chattiness over the wire (see Figure 2-5). By leveraging CSOM, developers were no longer required to deploy their solutions to the SharePoint server, and had an option for remotely deployed applications with reduced server touch and performance risk to SharePoint.

Figure 2-5. CSOM architecture

In addition to CSOM, SharePoint 2010 also added a new capability for partially trusted code or sandboxed solutions. Figure 2-6 clearly shows the advantage of this new capability as each solution can be isolated in its own worker process, which is managed by the User Code Service outside of IIS. This prevents custom-developed code from impacting SharePoint in the way that farm solutions can. Sandbox solutions also provide a system to measure the server impact of running code, and throttle the impact a solution can have on the resources of the farm. These capabilities make sandbox solutions appealing, as they are significantly “safer” to the health of the farm.

Sandbox solutions are great from a safety and isolation perspective, but they do have a number of capability limitations. Sandbox solutions must be deployed to each Site Collection on which they’ll be used, have a limited set of APIs they can call, and have a number of other restrictions. Some of those can be worked around by using a full-trust proxy to access a database or web service, but that proxy must be deployed as a full-trust farm solution. We won’t spend much time talking about sandbox solutions in this book, but they are a way to deploy some simple customizations to SharePoint without a farm solution in SharePoint 2010.

Figure 2-6. Full-trust solution versus sandbox solution

The Cloud App Model with Apps for SharePoint: SharePoint 2013

Microsoft is fundamentally changing how we deliver experiences with the new cloud app model. Apps for SharePoint are standalone applications that are easy to install, use, manage, upgrade, and remove. The cloud app model is designed for hosted, on-premises, and hybrid SharePoint deployments that leverage web standards to integrate code running outside SharePoint into the SharePoint user experience via public and private app stores.

The cloud app model provides a number of different options around where you can run your application code. Figure 2-7 walks through provider-hosted, auto-hosted, and SharePoint-hosted deployment models supported by SharePoint 2013.

Figure 2-7. SharePoint 2013 app model

The key thing to take away from this diagram is that none of the options involve running server-side code on the SharePoint Server. Applications run either client-side in the browser, on another web server, or on an automatically deployed instance in Windows Azure.

The new cloud app model reduces complexity by removing the custom app development process from SharePoint. Apps communicate with SharePoint via web services or CSOM, which provide the full power of the server API. This opens up SharePoint development to any web developer, regardless of platform.

SharePoint has become an incredibly rich ecosystem of features and tools. As business applications develop, the trend is to consume services from SharePoint and to surface our capabilities as an app rather than extend SharePoint in the ways we used to extend it.

Most business applications, regardless of industry, perform only a couple of core activities. They focus on collection and reporting of data to help the business gain new insights. Traditionally, application developers may have custom-coded a reporting solution or data visualizations into an application. Business intelligence was a separate activity done by BI professionals who created data marts and data warehouses, and focused on extract, transform, and load (ETL) tools, and on large Online Analytical Processing (OLAP) databases. Business intelligence was historically treated as its own process and sometimes even had its own team. With the new capabilities of SQL Server 2012, BI can become part of every solution we build. New in-memory databases make creation and processing of reporting structures quick and easy, while more powerful data visualization tools enable our information workers to do more independently. Figure 2-8 shows the architecture of the SQL Server 2012 business intelligence stack focusing around the client, BISM, and data sources that allow us to compose our solutions. In Part III, we’ll build out a BI Semantic Model, and we’ll explore the client tools in Part IV.

Figure 2-8. Architecture of the SQL Server 2012 BI stack

The approach you will learn in this book works without adaptation on LightSwitch 2011 or LightSwitch 2012, on SharePoint 2010 or SharePoint 2013, and on SQL Server 2012 or SQL Server 2012 SP1. In Visual Studio 2012 Update 2, Microsoft added support for publishing a Lightswitch application to SharePoint or Office 365 leveraging the new SharePoint cloud app model. Microsoft has shown that this is an area of significant investment; in future versions of LightSwitch, SharePoint, and SQL Server, expect to see new features that improve integration and add new capabilities.

This chapter should have provided you with a bit of context around each of the tools we’ll be using to build our solution. Our solution is a data-driven application designed around a help desk scenario. The database is the foundation of any business application, so we’ll start with a review of the rules of database design. Then we’ll move into the LightSwitch application, the BI Semantic Model, reports and data visualizations, and finally the tips and tricks you’ll need to make these tools work in your environment.

Welcome to the bold new world of business applications with SharePoint, LightSwitch, and SQL Server 2012. By leveraging the tools and patterns in this book, you’ll write less code and create better solutions that will evolve with your needs.