With RIA Services, it is easy to use your own business objects in your Silverlight application… once you have the basic plumbing in place. However, there are quite a few steps required to set up that plumbing. This post details the process of hooking up your business objects, RIA Services, and Silverlight.
So … you follow best practices and build business objects for all of the entities involved in your application. Or maybe you generate those business objects with something like Entity Framework (EF), Linq to SQL or other similar tool. In any case, you now want to use those business objects from a Silverlight application.
Seems like it should be easy, right? Just define a reference from your Silverlight application to your business object component and proceed just like with your WinForms or ASP.NET application. But no.
Silverlight does not allow you to set a reference to a non-Silverlight component. There are a number of ways you can deal with this:
- Use a Silverlight class library project type and build your business objects in there. Not a good solution if you are using those same business objects with other user interfaces.
- Build a WCF service that provides your business objects to your Silverlight application. You can find out more about this option here.
- Use Rich Internet Application (RIA) Services. This is a new Microsoft technology that is currently out in preview.
This post demonstrates option #3: Using RIA Services. The example presented in this post uses business objects you build yourself. These "home made" business objects are often referred to as POCO, or plain old CLR objects. Use the techniques presented in this post any time you start a new Silverlight application and want to access your POCOs from that application.
Tuesday, October 26, 2010
Silverlight, RIA Services, and Your Business Objects - Deborah's Developer MindScape
InfoQ: Debate: Microsoft’s RIA Services Code-generating Tools and Sound Architectural Principles
Some developers consider that Microsoft's RIA Services code-generating tools are teaching bad architectural principles to developers while others consider the tools useful if used properly.
Very simple applications can be built up rapidly without much thought given to their architecture. The presentation layer could access the database directly since there would be almost no business logic involved. But what happens if the application grows in complexity adding more and more business logic? Should the presentation layer be let to access the database directly? Solid architectural principles say “No” because such an approach introduces strong links between the two layers so a simple change in one of them has rippling effects in the other.
Microsoft technologies are known for offering code generating tools that make the life simpler for the developer at least at the first glance but are not really useful for large projects, and they are considered by some to teach bad lessons to new developers. RIA Services tools are no exception.
Friday, October 22, 2010
Silverlight Navigation With the MVVM Pattern - UK Premier Support for Developers - Site Home - MSDN Blogs
Silverlight Navigation With the MVVM Pattern
5 Oct 2010 2:00 AM
I recently had a query from a customer that was one of those ones that you think “Aha! That’s easy, you just do this”. Then you think a bit more about it and realise that if you want to do it properly it’s not quite as simple as you first thought.
This particular query related to how to use the navigation framework introduced in Silverlight 3 with the MVVM pattern. For those that don’t know the Model-View-ViewModel pattern is a common pattern often used to build Silverlight and WPF applications since it has strong support for databound UIs and provides good abstraction for unit testing and keeping your view logic separate from the view and the model.
Thursday, October 21, 2010
Creating RIA Services Solutions
Default Solution StructureIn the default solution structure, RIA Services creates a single client project and a single server project. When you create a new project with the Silverlight Application template and select the Enable WCF RIA Services check box, you create a solution with the default structure. A RIA Services link exists between the two application projects. When you build the solution, client code is generated for domain services and shared code. The following illustration shows the default solution structure.
The default solution structure is convenient because all domain service types and shared code added to the server project are automatically available to the Silverlight client project after you build the solution. Also, the shared code you add to the server project is visible in the client project. This structure works well when you do not have many domain services in the server project and you do not need to reuse business logic across many different Silverlight applications.
In a solution with the default structure, you can add more Silverlight applications with a RIA Services link to the server project. However, there are limitations of the default structure. The generated code for each Silverlight client can access all of middle-tier code from the server project. For example, if you have three Silverlight applications linked to a single server project and you want to add a domain service that will be used by only one of the Silverlight applications, all three client applications will have a generated domain context for the domain service and will be able to access that domain service.
For more information, see Walkthrough: Creating a RIA Services Solution. For more information about the code generated for a client project, see Client Code Generation.
Silverlight Business Application template
RIA Services also provides a Silverlight Business Application template. This template provides a convenient starting point for building a business application that utilizes Silverlight for the client. The template builds on the Silverlight Navigation Application and uses RIA Services to support authentication and user registration. When you create a project by using the Silverlight Business Application template, RIA Services creates the solution with the default structure. The Silverlight Business Application automatically adds the following features:
Login window
Registration window
Silverlight Navigation
The default authentication mode for the Business Application is Forms Authentication. To use Windows Authentication, you simply change the value of the authentication element in the Web.config file, such as <authentication mode="Windows"/>, and change the value of the Authentication property on the generated WebContext class. The Business Application template automatically contains code to support either FormsAuthentication or Windows Authentication. For more information, see Walkthrough: Using the Silverlight Business Application Template.
The Services folder of the server project contains the domain services that expose user registration and user authentication. The user registration service utilizes the ASP.NET membership provider to create new users. In the server project, a folder named Models contains classes for defining properties for user and registration data. You can add properties to these classes to customize the user data for your application.
In the client project, the Business Application contains code to simplify developing the presentation layer. The Libs folder and the Controls folder contain assemblies and controls that are used within the template. The Login folder (located within the Views folder) contains the authentication and user registration controls. These controls are automatically enabled in the project. The Resources folder (located in the Assets folder) contains resource strings for text within the project. As you add text to your application, you can add them to the file for application strings.
For more information, see Walkthrough: Using the Silverlight Business Application Template.
Silverlight 4 101: Silverlight Project Templates - Kevin McNeish [C# and .NET]
Silverlight 4 101: Silverlight Project Templates
