Silverlight Database Access through LINQ to SQL and ADO.NET

Devart LinqConnect supports Silverlight 4 and higher. With it you can develop rich web applications with true ORM support for database access. Moreover, LinqConnect allows using ADO.NET in Silverlight for database access, which was not available for Silverlight before. And in addition, it offers its own embedded database engine based on SQLite to store data in isolated storage using a fully functional local relational database.

Silverlight Database Access through LINQ and ADO.NET

All LinqConnect ORM features - high performance, wide LINQ support, LINQ to SQL compatibility - are available for Silverlight completely. LinqConnect brings you the possibility to use LINQ in Silverlight applications, which grants you such features as compile-time validation, IntelliSense, and your IDE's debugging mechanisms when building and testing your queries, etc.

Though Silverlight does not provide ADO.NET data access, with LinqConnect you can use ADO.NET in Silverlight applications. With LinqConnect you can employ the flexibility and performance of the native database SQL. LinqConnect Silverlight ADO.NET data access allows you to move existing data access code to this platform, providing wider capabilities for porting desktop applications to Silverlight.

Portable Domain and Data Access Layers

LinqConnect provides the same interfaces for accessing data on all the supported platforms. This allows you to share the same data access layer and domain layer between your application ports to different platforms, such as .NET Framework, Silverlight, Windows Phone 7 and 8, Mono, and Metro. For example, if your application should use SQLite database and be ported to Silverlight, LinqConnect allows you to share the same code for working with data in desktop and Silverlight applications.

LinqConnect for Silverlight can be used in XAML C# and Visual Basic applications.

Local SQLite Database for Silverlight

In many cases Silverlight applications need to store some data locally. Silverlight offers you to serialize and store data in isolated storage in XML format. However this is not always convenient to store data in XML format. You need to parse the whole file even if you need only part of the data, and XML format can be too inefficient if someone needs to store a significant amount of data locally.

Having a reliable and convenient storage for local data becomes even more important for Silverlight out-of-the-browser applications that can be installed locally and allow off-line usage, and LinqConnect suits perfectly for these needs. It offers you embedded database functionality, allowing you to store data in isolated storage on the client side in an embedded database. LinqConnect for Silverlight contains the ready-to-use SQLite embedded database engine from C# SQLite project. You don't need to install any additional software, just use LinqConnect to work with a fully-functional relational database in Isolated Storage.

Storing data in a relational database offers you a number of advantages - such as transactions, constraints, indexes, and generally provides higher performance and lesser file size. Using relational transactional database also increases reliability of local data storage. Small and efficient, and at the same time powerful SQLite database engine together with ADO.NET and LINQ interfaces for data access make LinqConnect a perfect choice to store data locally in Silverlight applications.

Limitations of Silverlight Local Database Functionality

Silverlight provides limited quota - isolated storage size - to applications, so it limits the database size. However, you may ask user to increase the quota size. Yet, trusted Silverlight out-of-browser applications are not subject to this restriction. Such applications can also store embedded SQLite databases in a file of a client file system without the isolated storage limitations. See the Trusted Applications article in MSDN for more details.

Connecting to Database in Silverlight
(Two-Tier vs N-Tier)

Silverlight itself does not provide the way to access data from database servers directly. To access such data, Microsoft offers one of the following ways: use Web Services, ADO.NET Data Services, or RIA Services that access data, materialize, serialize, and send them to your application in XML or JSON format. These ways involve the creation of additional data access layer that causes overhead for data serialization on the service side and deserialization on the client side. In addition, this increases the network traffic of the application because it transmits data in an excessive XML form, while database servers usually return it in much more compact binary form.

With LinqConnect you can connect to the following databases from Silverlight: Oracle, MySQL, and PostgreSQL. It allows you to use ORM LINQ in Silverlight as well as SQL and to create truly Client-Server (two-tier) applications, that work with data directly from your browser through the TCP/IP protocol, when n-tier architecture is objectional. It offers the following benefits:

• No need to create an additional data access layer
• No performance overhead for data serialization and deserialization
• Lower network traffic

Limitations of Silverlight SQL Database Connections

• Port Limitations
  Silverlight applications are allowed to connect only through a limited allowed range of the TCP ports (4502-4534), which does not correspond to the default ports used by database servers. So you need either to configure the database servers to use allowed ports or to use port forwarding.
• Policy File
  When establishing a network connection, Silverlight application requests a policy file from the server. The connection cannot be established if no proper policy file is returned, so the server needs to be configured to return a valid policy file via HTTP protocol for the corresponding request on TCP port 943 or on port 80.

You can see more details on these limitations in Network Security Access Restrictions in Silverlight.

However, trusted Silverlight out-of-browser applications are not subject to these restrictions, so you can connect to the database server on any port with them without requiring the policy file.