C H A P T E R  1

Forms Over Data and Beyond

If you've ever gone skydiving, you'll recognize that using Microsoft Visual Studio LightSwitch is much like a skydiving experience.

As you jump from the airplane at 10,000 feet, you'd see a magnificent view of countryside, cities, and towns linked together by roads, railways, and other pieces of infrastructure. A high-level view of LightSwitch is rather like that. It consists of several large pieces that are all interconnected and synchronized together.

Of course, jumping from an airplane can be scary and so too can using LightSwitch, particularly if you start to push toward the technical limitations of the product. Although this book doesn't provide a cure for vertigo, we hope that the contents will at least alleviate any fears of LightSwitch that you may have and help you get the most out of your development experience.

As we descend from that 10,000-foot view, we can see some more ways in which LightSwitch is like skydiving. Writing LightSwitch applications can be very fast. It can also be a lot of fun because you don't have to worry about writing the boring, repetitive boilerplate code you seem to have to write in other applications.

When we finally hit the ground (we hope, as lightly as a feather), you can look back on the experience and appreciate the thrill of what has just happened. We hope that with the help of this book, your journey into the advanced LightSwitch development adventure will be just as exciting.

Who Is LightSwitch For?

According to Microsoft, LightSwitch provides the “easiest way to build data centric applications for the desktop or cloud.” This focus on ease of use means that LightSwitch is often labeled as a tool for nondevelopers. But according to the architects behind the product, LightSwitch was never designed as a tool for nondevelopers. It was designed for an audience that Microsoft calls “breadth professional developers.” This group describes practical people with wide technical skills who look to technology to solve specific problems.

Since LightSwitch's release, it's attracted a wide audience of people from many different backgrounds and varying abilities.

During the early beta-1 days, LightSwitch was initially thought of as a natural successor to Access, kind of “Access.NET,” or even a “Microsoft Access for the web” as it were. Grouping LightSwitch and Access together was a natural association for many developers, because both products are data-centric rapid application development (RAD) tools. Because of these similarities, many Access developers are converting to LightSwitch. Many developers with experience in FoxPro and Excel/VBA are also using LightSwitch for the same reason.

Meanwhile, information technology (IT) departments and decision makers have found that LightSwitch provides the perfect tool for power users, and they have encouraged this group of users to turn to LightSwitch. Power users are highly intelligent individuals who've not selected IT as their chosen career path but are experts in some other business domain. However, they've found themselves developing applications to help perform their main job function.

Because these individuals haven't been trained to program computers, they might cobble together an application (perhaps using Access and Excel) to solve a specific business problem. But if the individual leaves or if the application needs to scale, it becomes notoriously hard for IT departments to support such solutions. LightSwitch applications are easier for IT departments to maintain because they can leverage their existing .NET and SQL Server skills. Because LightSwitch uses a three-tier architecture and actively guides the developer toward writing code in the right place, it's more difficult to write applications badly in the first place.

Farther up the scale, LightSwitch attracts many professional developers who have come from .NET, ASP.NET, and Silverlight backgrounds. These professional developers realize how much time LightSwitch can save them, so they have embraced the product. They understand how useful LightSwitch can be for developing forms over data applications and how easy it is to write web-based applications with it.

We've therefore seen that LightSwitch attracts a wide audience, but all of these groups share one thing in common. They see LightSwitch as a serious tool for solving business problems and understand how powerful it can be.

The rest of this chapter shows you how LightSwitch stands out from the crowd and discusses some of the key technologies that have gone into the product. We'll start by giving you a high level overview and then cover the following topics:

• The model centric architecture of LightSwitch.
• The data, logic, and presentation tiers.
• How the Model-View-ViewModel pattern applies to LightSwitch.
• How a LightSwitch application actually works.

The 10,000-Foot View

LightSwitch applications conform to a traditional three-tier architecture, containing presentation, application (business logic), and data tiers. This has many advantages and benefits. In addition to being modular (a good practice), the three-tier design provides a scalability that was sorely missing from Access applications and enables tiers to be replaced or modified without affecting others. To give an example, Microsoft may choose to replace the current Silverlight client with an HTML/JavaScript client or some other emerging technology in a future version. The three-tier architecture makes this possible without the whole application needing to be rewritten. In fact, active members of the LightSwitch community have already written several articles about creating HTML frontends to LightSwitch.

At the presentation level, the client is a Silverlight 4.0 application, running either inside a browser or as an OOB (out-of-browser) desktop application. The client connects to middle tier logic using WCF-RIA (Windows Communication Foundation–Rich Internet Applications) services. The middle tier itself also consists of a set of WCF-RIA domain services running under ASP.NET 4.0.

If you're unfamiliar with RIA services, this technology was introduced in 2009 and is used to marshal data between a database and the LightSwitch application. Specifically, RIA services coordinate the application logic between the middle and presentation tiers. The biggest benefit it provides is that it significantly simplifies the development of n-tier solutions in a RIA web environment such as Silverlight.

At the data tier level, Microsoft SQL Server is the database of choice. You can also attach to other data sources, including SQL Azure, SharePoint 2010, and custom adapters written using RIA domain services. Connections to SharePoint technically take place using an OData (Open Data Protocol) endpoint exposed by the SharePoint API (Application Programming Interface).

LightSwitch utilizes the power of the Microsoft ADO.NET Entity Framework 4.0. This is an ORM (Object Relational Mapping) system, which was first introduced in .NET 3.5. One of the key benefits of using an ORM is that it abstracts away the schema of the database from the conceptual view that is visible in code. It eliminates the problem of what is commonly known as the object relational impedance mismatch that is often experienced in database-oriented applications. In simple terms, an ORM allows you to refactor database tables without affecting the view of the data in code.

To query data from LightSwitch, you can use LINQ (Language INtegrated Query). This was also introduced in .NET 3.5 along with Entity Framework V1. LINQ provides a set of common query operators, the biggest advantage being that you can use the same syntax for querying various different data sources. For example, you can just use LINQ rather than having to learn the individual, and very different, syntaxes of query technologies like T-SQL, XPath, LDAP, and the various other query languages that would otherwise be necessary to query different types of data. If you're using LINQ for the first time, a tool called LinqPad (www.linqpad.net/) provides a greatly simplified and easy-to-use learning environment.

Architecturally, LightSwitch is based on a model-centric architecture. Applications are authored in terms of building blocks such as entities, screens, and data services that are animated by the LightSwitch runtime (using Silverlight and .NET technology stacks). Having these building blocks means that the LightSwitch business logic doesn't have a specific technology dependency. LightSwitch incorporates all of these proven .NET technologies along with best practices for their use. Any application you create using LightSwitch will therefore also be based on this solid foundation.

Figure 1-1. LightSwitch components

Figure 1-1 shows the three tiers that make up a LightSwitch application and identifies the main components that belong to each tier. We'll now explain each tier in more detail.

WHY THE NAME LIGHTSWITCH?

Model-Centric Architecture

LightSwitch is based on a model-centric architecture. What exactly do we mean by this and why is it important?

When you're writing a LightSwitch application, imagine that you're a bricklayer rather than a programmer. The raw materials at your disposal include entity, query, screen, and control building blocks. To build an application, you simply put these building blocks together in the appropriate way. The important analogy here is that building blocks are the main construct used for building applications, not code. Figure 1-2 shows the building blocks that are defined by LightSwitch.

Figure 1-2. LightSwitch building blocks

When you create a new project, LightSwitch creates a new empty model (which we'll refer to as the LSML model). This model takes the form of an XML file called ApplicationData.lsml. When you create a new screen in your application, LightSwitch adds the XML markup that represents a screen building block into your ApplicationData.lsml file. The same thing happens when you add data sources, tables, and queries. At the end of the design process, your application is expressed entirely in XML.

On its own, XML isn't capable of doing very much—after all, it's just data. Something needs to turn these data into a functioning application, and this role is carried out by the LightSwitch runtime.

The LightSwitch runtime comes into action when a user actually runs your application. It reads the model and performs many other functions such as loading the application, authorizing access, and retrieving data. The LightSwitch runtime consists of the many technologies that were mentioned earlier, such as Silverlight, WCF, Entity Framework, and the DLLs that belong in the Microsoft.LightSwitch namespace. The runtime runs on both the client and logic tiers.

The beauty of this architecture is that it abstracts the definition of your application away from the actual implementation. Hypothetically speaking, some other runtime could be written and used instead. This new runtime might target different devices or operating systems. The benefit of the architecture is that it doesn't impose any solid dependency on any specific technology. The model-driven design therefore makes LightSwitch more extensible and more future proof.

The Data Tier

As mentioned earlier, LightSwitch provides first-class support for reading and writing to SQL Server, SQL Azure, and SharePoint 2010 data sources. You can very easily create screens to display data, and you can even display data from multiple data sources on a single screen.

LightSwitch also depends on a special SQL Server database called the intrinsic or ApplicationData database. Any users and tables that you create in LightSwitch are added to this database.

When you run or debug a LightSwitch application at design time, LightSwitch hosts your intrinsic database using a local instance of Microsoft SQL Server Express. At design time, a local instance of SQL Server Express must be used and other editions of SQL Server are not supported. In production, however, this restriction doesn't apply, and the intrinsic database can be hosted using any version of Microsoft SQL Server 2005 or above, as well as Microsoft SQL Azure.

When you run an application at design time, an intrinsic database is created and any data you enter are persisted between debug iterations.

However, you should treat these data as temporary because any major changes made to your data schema can force the intrinsic database to be deleted and re-created. (LightSwitch will warn you before it does this to prevent data loss.) Another important point is that any data entered during design time won't be retained when you deploy your application.

For security, LightSwitch uses the ASP.NET SQL membership provider, and if you take a peek inside the intrinsic database, you'll see the tables that are used. Examples include the dbo.aspnet_Membership, dbo.aspnet_Roles, and dbo.aspnet_Users tables.

At design time, the intrinsic database is created, re-created, and updated dynamically by LightSwitch using the table definitions you've specified in the designer. Specifically, it generates the intrinsic database schema using the modeled EntityContainer building block.

The Logic Tier

The logic tier can also be known as the middle tier, business layer, or business logic layer. Its main task is data access and processing.

For each data source you add to your application, LightSwitch creates a corresponding data service in the logic tier. A data service encapsulates the data access operations on a data source and is exposed as a public service endpoint at the logic tier boundary. The Silverlight client uses this data service to carry out data access that is needed for a given data source.

Data services expose entity sets, which contain operations for retrieving, updating, and saving data. An entity set is a container for items of the same entity, and all data access is carried out through an entity set.

By default, each entity set contains all and single queries, which return all records and single records by primary key. The queries you create yourself are also exposed as an entity set operation. Figure 1-3 illustrates the relation between data services, entity sets, and operations.

Figure 1-3. Data service, entity sets, and operations

When a query is executed, it passes through the query pipeline. The query pipeline exposes various points in the lifecycle of a query that you as a developer can intercept and inject with custom code. During the preprocessing phase, for example, you can tailor the results of a query by appending additional query operators using LINQ.

Each entity set also includes a single built-in operation called SaveChanges. When working with a LightSwitch application, the client maintains a set of all the added, updated, and deleted records in an object called a change set. When the user clicks the save button on a screen, the change set is passed to the logic tier and the SaveChanges operation is called. At this point, the processing enters the save pipeline and, just as with the query pipeline, the save pipeline can be intercepted with custom code. Figure 1-4 shows the phases in the save and query pipelines and highlights some of the points where you can write your own code.

Figure 1-4. The Save Pipeline and Query Pipeline

When updates are applied at the database, LightSwitch uses optimistic concurrency and doesn't apply any locks to the database. If concurrency violations are encountered, it alerts the user and displays a dialog with the proposed, current, and server values. The SaveChanges operation also takes place inside a transaction, and all data changes are committed atomically. Either all changes are saved successfully or no changes will be saved at all.

Data Providers

When LightSwitch creates a data service, it configures the data service to work with a data provider that corresponds with the data storage service that's used (e.g., the database). The data provider offers a set of libraries that enables the logic tier to communicate with the storage service. Table 1-1 shows the data providers that LightSwitch uses.

Although LightSwitch uses the Entity Framework to connect to the SQL Server, you don't need to understand how this works, nor do you need to learn how to use the Entity Framework API. When you're writing code, LightSwitch produces entity classes that allow you to get to your data easily and naturally. For instance, you can use the following code to retrieve a customer surname: ApplicationData.Customer.Surname. LightSwitch makes it really simple and intuitive for you to work with data.

The Presentation Tier

The presentation tier controls what the user sees and does. It's responsible for showing data to the user, allowing data entry to happen, and all other tasks that relate to human interaction. Importantly, it also performs operations such as data validation and it keeps track of data changes and interacts with the data services in the logic tier.

The activities of the LightSwitch client can be summarized into the following three categories:

• User interface (UI),
• Client business logic,
• Data service access.

Everything that happens on the client is encapsulated inside the LightSwitch shell. From a top level, the hosting, shell UI, and theming services are the parts that make up the shell, and this is shown in Figure 1-5. We'll now describe the parts that make up the client in more detail.

Figure 1-5. The LightSwitch shell

Screens

A screen represents a piece of user interface that is used to view or enter data, just like a form in an Access application. Multiple screens can be opened in a LightSwitch application, but there can only be one single active screen at any time.

Each screen contains a data workspace that is used for fetching and managing data. The data workspace manages the state of the data in a change set, and this is submitted to the data service on the logic tier when the user initiates a save.

Because each screen contains its own data workspace, data changes made in one screen are not reflected in other screens. Data cannot be shared between screens, and each screen retains an independent view of the data.

Other important concepts include the screen object, screen layout, and visual tree.

You can think of the screen object as a business object that contains no UI. When designing a screen, you can access data in code and add items such as properties or screen parameters. All of these objects are exposed in code through the screen object.

The screen layout and visual tree are concepts that emerge at runtime. We'll describe both of these in the “MVVM Applied to LightSwitch” section later in this chapter.

Hosting Process

LightSwitch applications are hosted using the Silverlight runtime. One of LightSwitch's most useful features is that an application can be configured to run either out of browser, as a desktop application, or inside a browser, without having to be rewritten. You can switch an application from one mode to the other by simply setting a radio button option in the properties of your LightSwitch project.

Browser applications are hosted by the Silverlight runtime inside the browser. Users install the Silverlight runtime as a browser plug-in, and supported web browsers include Internet Explorer, Firefox, Safari, and Chrome. Browser applications execute inside a sandbox, and access to features such as Export to Excel is prohibited. Access to certain parts of the file system is also restricted.

Desktop applications are hosted by the Silverlight out-of-browser host service (sllauncher.exe). LightSwitch configures your application to require elevated permissions, which give access to features such as Export to Excel, and COM-based automation.

When you're writing LightSwitch applications, it's useful to know if your application is running as a browser or a desktop application. Before you perform any COM-based operation such as automating Outlook, it's a good idea to check where your application is running by writing some code. Chapter 11 includes code that shows you how to do this.

WILL LIGHTSWITCH RUN ON MACS, LINUX, OR MOBILES?

The Shell UI

The shell UI is a key part of the LightSwitch presentation layer, and it controls what's visible to the end user. It provides the user interface logic that performs tasks such as logging in, generating, and activating screens.

You can change various aspects of the shell's behavior for each LightSwitch application using the properties pane of your project (Figure 1-6).

Figure 1-6. Changing the shell and the theme settings in the project's property tabs

LightSwitch ships with one standard default shell, which will be familiar to any LightSwitch developer. As the LightSwitch market matures, additional shells from third party vendors and members of the community will become available (either free or for sale).

Figure 1-7 illustrates the standard screen sections you'll see using the default LightSwitch shell. These include:

• The screen region. The central area where screens are displayed.
• The navigation region. Used for launching and activating screens.
• The command region Displays command buttons such as Save and Refresh.
• The validation region. Used for displaying any validation errors.

Figure 1-7. Default screen regions

Figure 1-8 shows the Outlook shell that was developed by Infragistics. It highlights just how radically the look and feel of an application can be modified.

As shown in the illustration, this shell allows screens to be tiled rather than tabbed, it displays a screen command bar section for each screen instead of showing a ribbon bar, and includes a slider control on the right-hand side that lets you increase or decrease the number of screens shown in the middle pane.

Figure 1-8. Infragistics's Outlook style shell

If you choose to do so, you can also write your own custom shell extension, and Chapter 10 shows you how to do this. When writing your own shell extensions, LightSwitch exposes various views models that you can consume. The types of data that you can bind to in a custom shell include:

• Current user,
• Application logo,
• Screen activation and navigation,
• Active screens,
• Screen commands,
• Screen validation errors.

It's worth pointing out that the four screen regions in the default shell that were mentioned earlier (see Figure 1-7) are not concepts that are strictly defined in LightSwitch. The shell implements the layout using the view models mentioned above, and you could, for example, choose to create a shell that doesn't include any of the elements in the navigation region.

The Theming Service

The theming service makes up the final part of the presentation layer. You'd use a theme to apply a set of presentation preferences, such as fonts and colors. Unlike changing the shell, the visual changes applied by a theme are more subtle.

Like shells, themes are also applied using the properties pane for your project. Themes are often designed to work with a specified shell, but it is entirely possible for shells and themes to be mixed and matched.

Themes and shells enable a consistent look and feel to be applied to the various parts of your application. It can often be a struggle for those new to LightSwitch when they try to set various control attributes (such as its font and its color) at a screen level, because many of these attributes are designed to be controlled by a theme, rather than set for each individual control.

Themes are also one of several LightSwitch extension points, and Chapter 10 shows you how you can create your own custom theme.

Model-View-ViewModel (MVVM)

Applications that you create in LightSwitch are based on the M-V-VM pattern (also known simply as MVVM). Like many other software patterns, MVVM is designed to:

• Ensure a clean separation of concerns.
• Make applications more maintainable and more testable.
• Simplify UI design.

You don't need to do anything extra in your code for MVVM to work. LightSwitch automatically takes care of this for you. In this section, we'll show you the advantages that it offers, and we'll begin by explaining the history behind this pattern.

Software design is complex by nature, and programmers have always searched for ways to make things easier. Just the UI layer alone is responsible for user interaction, validation, data access, and client-side business logic. Without any real pattern in place, applications can easily get out of hand.

To add structure and simplify the job of software design, a pattern called Model View Presenter (MVP) has gained much popularity in developer circles. This is a variation of the Model View Controller (MVC) pattern, which has existed since 1979.

The Model part of MVP refers to data, Views are what you seen on the screen, and the Presenter element hooks the two together. A key characteristic of this pattern is the role that's played by the presenter. The presenter populates the view with data, carries out validation, and reacts to user input.

Like all things in life, patterns evolve, and in 2004, Martin Fowler published his Presenter Model (PM) pattern. You can find further details about this pattern on his web site: http://martinfowler.com/eaaDev/PresentationModel.html.

Just like the earlier patterns, the PM pattern features views that are separated from their state and behaviors. However, this pattern also includes an abstraction of view called a Presentation Model. The view becomes a rendering of the Presentation Model, which contains little or no code and is frequently updated by the Presentation Model. Both the Presentation and View Models are therefore closely synchronized.

In 2005, John Gossman (a technical architect at Microsoft for the Silverlight and WPF (Windows Presentation Foundation) products) unveiled the MVVM pattern. In simple terms, MVVM is a tailor-made version of the Presenter Model that targets the WPF and Silverlight platforms. In fact, the only real difference between the PM and MVVM patterns is the explicit use of the WPF and Silverlight data-binding capabilities.

The MVVM pattern is highly characterized by the role of the View Model. The responsibilities of the View Model include:

• UI logic. For example, data validation.
• Data conversion. If you want to display integer data using a slider control that renders decimal data, the View Model does the necessary conversion and coercion.
• Storing the state of the UI. If you're showing a collection of data through a data grid and the user selects a record, the View Model can keep track of the currently selected record.

According to the MVVM pattern, the view should only concern itself with the presentation of data and could be virtually code free. Views should only really display the data from the View Model and do no more than absolutely necessary.

An application designed around MVVM allows you to easily switch controls in and out. You'll see this when you start working with LightSwitch. For example, the data item that represents a surname can be easily changed to use a label, textbox, or any other control that supports the underlying data type (in this example, string).

The View Model communicates with the view through data binding. The View Model exposes properties that the view can bind to. Therefore, the view doesn't need to know anything about the View Model and means that the two are loosely coupled.

This helps to establish a clear separation of concerns, the aim of which is to separate the parts that make up a system into logically distinct pieces. By splitting out functionality in this way, it enables applications to be created that are cleaner, more maintainable, and more testable. Because LightSwitch is based on MVVM, your applications will benefit from the advantages that it brings.

Understanding the role of the view and the View Model is extremely important when writing Custom Controls, because it is easy to include logic in the control that really belongs in either the model or the View Model. You can find out more about Custom Controls in Chapter 9.

MVVM Applied to LightSwitch

Due to the model-based architecture of LightSwitch, the MVVM pattern only emerges at runtime. This can make it a bit tricky to understand at first. The following list shows the parts that make up the MVVM pattern and how they relate to LightSwitch:

• Model = entity and screen data objects
• View Model = screen ContentItems (these are generated at runtime)
• View = Silverlight controls.

The Model part of MVVM is the conceptual representation of the data. It consists of the entities and queries that are defined in your application.

At runtime, LightSwitch constructs the screen layout dynamically by interpreting your LSML model. The screen layout contains a tree of content items, which could represent data items, lists, commands, or parent items. A content item at runtime represents the View-Model element of MVVM.

Finally, the runtime builds the Silverlight visual tree. This object contains the actual tree of Silverlight controls, which is shown to the user. These Silverlight controls make up the View part of MVVM.

Figure 1-9 shows how the elements of MVVM map to the items on the screen designer. These types of illustrations are difficult because the screen designer is an expression of the LSML data model, whereas MVVM pattern is something that only emerges at runtime. However, this is still useful to help illustrate how the MVVM pattern fits in.

Figure 1-9. View and View-Model illustrated through a screen

As shown in Figure 1-9, the items that appear on the left-hand side of the screen designer (entities and screen data objects) are the Model part. Similar illustrations have been published that label the items on the left-hand side as the View Model. But just to avoid any confusion, the entities and screen data objects actually represent the Model part of MVVM.

When you run your application, the LightSwitch runtime generates content items for each data item on your screen. The content item makes up the View-Model part of MVVM.

The screen designer allows you to change the control for each data item in your screen. The control that you select is the view.

The LightSwitch Application Lifecycle

If you've worked with .NET in the past, you may be curious as to how everything ties together in LightSwitch. This section describes the lifecycle of a LightSwitch application. Specifically, it explains what happens during the design, build, and runtime stages.

Figure 1-10. LightSwitch build and run process

Figure 1-10 illustrates the LightSwitch development process in the form of a diagram. The columns in the diagram show the client, server, and common logic parts of your application. The common logic is executed on both the client and server. You'll see in Chapter 2 how LightSwitch creates a .NET project called Common that contains this logic

To make sense of this diagram, we'll start off at the bottom. This section represents the tasks that are carried out in the LightSwitch designer. As mentioned earlier, LightSwitch applications are constructed using building blocks. When you add screens, tables, or data sources using the designer, the XML mark-up that represents these building blocks are added to your ApplicationData.lsml file. The bottom section of Figure 1-10 highlights how:

• The Application and Screen building blocks are used to build the client.
• The Entity and Query building blocks are built into the common project.
• The DataService building block is used to build the code that runs on the server.

When you build your LightSwitch solution (or press the F5 key), LightSwitch compiles the client, server, and common code. During this stage, it compiles (and autogenerates where necessary) the following types of code:

• The user code and business logic that you've written. This includes the VB or C# code that you've written to handle the click of a button, or any user code that customizes the results of a query.
• Screen and entity classes. If you've created a table called customers, for example, LightSwitch generates a corresponding entity class called customers that you can call in your code.
• The “framework” that supports your LightSwitch application. For example, this includes the data access classes that are used in each tier and items such as the Application and DataWorkspace objects, which we'll refer to in later chapters.

An important point to remember is that UI elements are not compiled into your Silverlight client. When a user runs your application, the client carries out a process called dynamic runtime generation. This is the process that generates the user interface for your application.

So how exactly does the LightSwitch client render a screen? At compile time, LightSwitch embeds a copy of your LSML file inside the Silverlight XAP file (think of the XAP file as your compiled Silverlight application). This allows the LightSwitch client to access the contents of your LSML file. When a user opens a screen, LightSwitch searches for the corresponding screen building block in the LSML file. When it finds the screen, it builds the screen layout by constructing a tree of ContentItems. As you'll recall, content items make up the View-Model part of MVVM.

After building the content item tree, LightSwitch creates the Silverlight visual tree. It works out the Silverlight control to use by reading the Control setting that's stored against each ContentItem building block. The Silverlight control makes up the View part of MVVM.

If you're familiar with Silverlight, you might wonder if XAML (Extensible Application Markup Language) comes into play during this process. LightSwitch generates the Silverlight controls dynamically when the visual tree is built and, therefore, there isn't any XAML involved in the process. However, you can design your own custom controls using XAML, and Chapter 9 shows you how.

After dynamic runtime generation, the screens and controls are composed using MEF (Managed Extensibility Framework) and data templates.

LightSwitch also composes the shell at runtime using MEF. It works out the shell to use by reading the details held against the Application building block in the LSML file.

Summary

This chapter introduced you to Microsoft LightSwitch. LightSwitch is a tool that allows you to quickly develop data-centric applications for the desktop or web. In this chapter, we've shown you:

• The technologies that LightSwitch uses.
• The role of client and server tiers.
• How LightSwitch uses a built in intrinsic database.
• How the MVVM pattern applies in LightSwitch.

LightSwitch applications are built using well-known patterns and best practices such as n-tier application layering and MVVM, as well as technologies such as Entity Framework and RIA services.

LightSwitch uses a model-driven architecture. The definition of your application is saved in an XML file called ApplicationData.lsml. When a user runs your application, the LightSwitch runtime turns this XML model into a fully functioning application.

LightSwitch relies on a special database called the intrinsic database. This database stores the tables you create within LightSwitch, as well as security details such as login names and security roles. If you want to connect to external data, the data sources you can use include SQL Server, SharePoint 2010, and custom RIA services.

The logic tier (or middle tier) is responsible for performing data access and processing. LightSwitch creates a data service for each data source in your application. The LightSwitch client calls data service operations to insert, update, or retrieve data. All data operations pass through either the save or query pipeline. These pipelines expose points where you can inject your own custom code.

On the client, LightSwitch applications are based on Silverlight 4.0. Web applications are hosted using the Silverlight runtime inside your browser. If you choose to create a desktop application, LightSwitch generates a Silverlight out-of-browser application.

Within your application, screens are used for data entry and retrieval. Each screen maintains an independent view of your data using a data workspace.

You can easily alter the appearance of your application by changing the shell and theme settings. Changing the shell allows you to radically change the appearance of your application. More subtle changes (such as changes to font colors and sizes) can be made by changing the theme.

The MVVM pattern helps to enforce a clean separation of concerns. This means that LightSwitch applications are broken down into distinct features with minimal overlap. A feature of the MVVM pattern is that the view is as dumb as possible and contains minimal code. This makes it very easy in LightSwitch to change the controls that are used to render your data.