Creating a New Data Source
Tables are primitive data containers. A table represents a series of items of the same type. For example, a table can represent a list of customers or of employees or of cars or of any object that has some properties. Tables are divided into rows and columns. A row represents a single item. For example, if you have a table storing a list of customers, a row represents a single customer in the list. In LightSwitch terminology, a single item is referred to as an entity, and a list of items is called entity collection. Columns represent properties of the elements that the table stores. For example, a customer has a company name, an address, and so on. This information is represented with columns. In LightSwitch terminology, a column is also referred to as a property. Actually, columns also allow you to specify the type of the property (such as date and time, strings, numbers), as detailed later in this section. Continuing with the creation of this application, the first step is to create a new entity that will represent a single person in the contacts list. Do so, and name it Contact. In the LightSwitch Designer, click Create New Table. Doing so opens the Table Designer, as shown in Figure 3.2.
Figure 3.2. The Table Designer shows a new empty entity.
Here you can design your entity by specifying its properties. By default, the focus is on the entity’s title, which is Table1Item. Rename this Contact.
At this point, you can begin designing your new entity by adding properties. Notice that, by default, LightSwitch adds an Id property of type Integer (a type representing integer numbers), which identifies the entity as unique in the table (this is why such a property cannot be edited or removed). Therefore, such a property is an auto-incrementing index that is incremented by one unit each time a new element is added to the table. If you have some experience with other data-access tools such as Microsoft SQL Server or Microsoft Access, you might think of this as an identity field.
Adding Entity Properties
Each property has three requirements: the name, the type, and whether it is required (meaning that the information is mandatory or not). With regard to an entity that represents a contact, the first property you may want to add is the last name. So, click inside the Add Property field under the Name column and type LastName. Remember that property names are alphanumeric combinations of characters and digits and cannot contain blank spaces. If you want to provide some form of separation between words, you can use the underscore (_) character or you can use the so-called camel-case notation, where the words that compose an identifier start with an uppercase letter. LastName is an example of a camel-case identifier. LightSwitch automatically sets labels in the user interface to contain a space between camel-cased words automatically.
After you type the property name, you can press Tab on the keyboard to switch to the Type field. You can see the list of available data types and select a different one by expanding the Type combo box. By default, LightSwitch assigns the String type to each newly added property. Because the last name is actually a string, you can leave unchanged the default selection. Before providing the full list of available data types, let’s focus on the Required field. You mark a property as required when you want to ensure that the user must provide information for that property. In this example, the last name is mandatory because it is the piece of information that allows the identification of a person on our list of contacts, so Required is checked. LightSwitch marks new properties as required by default, so you need to manually unselect the box if specific property information is optional. Figure 3.3 shows the result of the previous addition.
Figure 3.3. The new property has been added to the entity and marked as required.
Each entity can expose different kinds of information. This is accomplished by assigning the most appropriate data type to each property. Before adding more properties to the Contact entity, it is important for you to understand what data types are and what data types Visual Studio LightSwitch offers.
Understanding Data Types
Whatever tasks your application performs, it manipulates data. Data can be of different kinds, such as numbers, strings, dates, or true or false values. When you add a property to an entity, you need to specify its data type to clarify what kind of data that property is going to manipulate. Visual Studio LightSwitch provides some built-in data types that are based on types exposed by the .NET Framework 4.0 and that in most cases are sufficient to satisfy your business needs. Table 3.1 summarizes available data types.
Table 3.1. Available Data Types in Visual Studio LightSwitch
Data Type |
Description |
Binary |
Represents an array of bytes |
Boolean |
Accepts true or false values |
Date |
Represents a date without time information |
DateTime |
Represents a date including time information |
Decimal |
Represents a decimal number in financial and scientific calculations with large numbers (a range between -79228162514264337593543950335 and 79228162514264337593543950335) |
Double |
Represents a large floating number (double precision) with a range from -1.79769313486232e308 to 1.79769313486232e308 |
Email Address |
Represents a well-formed email address |
Image |
Represents an image in the form of binary data |
ShortInteger |
Represents a numeric value with a range between -32768 and 32767 |
Integer |
Represents a numeric value with a range between -2147483648 and 2147483647 |
LongInteger |
Represents a numeric value with a range between -9223372036854775808 and 9223372036854775807 |
Money |
Represents a monetary value, including the currency symbol and the appropriate punctuation according to the local system culture |
Phone Number |
Represents a well-formed phone number according to U.S.-supported formats |
String |
Represents a string |
Guid |
Represents a globally unique identifier, which is a complex, randomly generated number typically used when you need a unique identifier across different computers and networks |
Using the appropriate data type is very important because it makes data manipulation easier, provides the right mapping against the back-end database, and in most cases can save system resources. As an example, instead of using a String to represent a date, you use the Date type. This is useful (other than natural) because SQL Server has a corresponding data type and the .NET Framework provides specific objects for working with dates if you need to write custom code. The same consideration applies to numbers, Boolean values, and binary data.
The Concept of Business Data Types
In Table 3.1, you might have noticed something new in the LightSwitch approach to data types. In contrast to other development tools and technologies, including .NET Framework 4 and Visual Studio 2010, LightSwitch introduces the concept of business data types. For example, suppose you want to add a property to an entity for inserting or displaying monetary information. Before LightSwitch, this was accomplished by using the Decimal data type, which can display decimal numbers and is therefore the most appropriate .NET type in this scenario. This is correct but has some limitations: For example, you must write some code to add the currency symbol or format the information according to the local system culture. Next, consider email addresses. Developers usually represent email addresses with the String data type but they have to implement their own validation logic to ensure that the string is a well-formed email address. The same is true for phone numbers. This approach makes sense in a general-purpose development environment such as Visual Studio 2010. But Visual Studio LightSwitch is a specialized environment focusing on business applications, so the LightSwitch team at Microsoft introduced four new data types, specifically to solve business problems:
- Money, a data type for displaying currency information that provides the appropriate currency symbol and culture information according to the user’s system regional settings.
- Image, which allows storing and returning an image in the form of binary data.
- Email Address, which accepts only valid email addresses and implements validation logic that throws errors if the supplied email address is not well formed.
- Phone Number, which accepts only valid phone numbers and which implements validation logic that throws errors in case the supplied phone number is not well formed. This data type can be customized to accept phone numbers in a format different from the default one, built specifically for the United States.
If you think that any data-centric applications must validate the user input to ensure that the entered data is valid, business data types can save you a lot of time, especially because you do not need to write the validation logic: LightSwitch does it for you. You will get a visual sensation of the power of business data types in this chapter when you run the application and test the validation functionalities. In addition, Visual Studio LightSwitch provides an extensibility point where you can add custom business types, as described in Chapter 19, “LightSwitch Extensibility: Data and Extension Deployment.” Now you know everything important about data types in LightSwitch and are ready to complete the design of the Contact entity by adding specialized properties.
Building a Complete Entity
So far, the Contact entity exposes only the LastName property, so it needs to be extended with additional properties that complete the single contact information. Table 3.2 shows the list of new properties (and their data type) that are added to the entity. You add properties by clicking inside the Add Property field and specifying types from the drop-down Type combo box, as you learned earlier.
Table 3.2. Properties That Complete the Contact Entity
Property Name |
Type |
FirstName |
String |
Age |
Integer |
Address |
String |
City |
String |
Country |
String |
PostalCode |
String |
|
Email Address |
HomePhone |
Phone Number |
OfficePhone |
Phone Number |
MobilePhone |
Phone Number |
Picture |
Image |
JobRole |
String |
None of the new properties is required because the entity already provides two ways to identify a contact as unique: the Id property and the LastName property. After you complete adding properties, the Contact entity looks like Figure 3.4.
Figure 3.4. The Contact entity has been completed.
The Contact entity represents a single contact, but Visual Studio LightSwitch also generates a Contacts table that represents a list of items of type Contact. If you open Solution Explorer and expand the Data Sources node, you can see how such a table is visible, as demonstrated in Figure 3.5. If you name your entities with words from the English language, LightSwitch automatically pluralizes the entity’s name when generating the table, thus providing the appropriate name for the new table.
Figure 3.5. The new Contacts table is visible in Solution Explorer.
Now that you have successfully created a new entity and a table for storing a list of entities, you might wonder where data is stored by your application. This is briefly explained in the next subsection and is revisited in Chapter 12, “Dissecting a LightSwitch Application.”
Data Storage
LightSwitch applications use the Microsoft SQL Server database engine to store their data. In fact, one of the prerequisites when you install LightSwitch is the presence on your development machine of SQL Server Express Edition. Supported versions are 2005, 2008, and 2008 R2. When you create an application, Visual Studio LightSwitch creates a SQL Server database for the application itself, also known as the intrinsic database, naming such a database ApplicationDatabase.mdf. This is the physical storage for your data until you run the application on the development machine. When you deploy the application to a web server or a networked computer, you also need to deploy the database. You can decide to export the current database and attach it to the running instance of Microsoft SQL Server, and its name is replaced with the name of the application (for example, ContactsManager.mdf). Alternatively, you can let the deployment process build and attach to SQL Server a brand-new database with a different name, but you can also publish the database in the cloud by deploying it to your SQL Azure storage. LightSwitch can perform these tasks for you, especially if you use the one-click deployment systems covered in Chapter 10, “Deploying LightSwitch Applications.” For now, you just need to know that data is stored into ApplicationDatabase.mdf, which is located in the %ProjectFolder%\Bin\Data folder.