Currently I have a working Silverlight application that uses .Net RIA Services.

It's structure:

Client-side

• Application.Client.UI.dll (Xamls and basic UI stuff)
• Application.Client.BL.dll (Contains the Link to RIA and most of the business logic)

Server-side

• Application.Server.Data.dll (Server-side dll that holds the Entity-model and it's generated domain service)
• Application.Server.Web.dll (Only the ASP.net hosting container, which references the Application.Server.Data.dll)

I placed most of the business logic on the client side (Application.Client.BL.dll) for better user-experience (fast reactio开发者_JS百科ns) and to free up server resources. My challenge is now to re-use this client-side dll including it's RIA data access capabilities, in a server-side windows service. I'm wondering, is that possible at all? Is the Application.Client.BL.dll still able to consume the existing RIA service, or does that dll require the Silverlight runtime to identify/locate it's service target, and therefore will not work anywhere else.

Curious for your answers

---

You really shouldn't put any business logic on the client, the guys in security and / or architecture will hate you for it ;-). Furthermore you can't use Silverlight assemblies in ASP.Net or Desktop projects and vice versa. If memory serves correctly, Silverlight uses an entirely different CLR altogether.

---

I encountered similar needs when working with compact framework assemblies I also wanted to compile for the full framework. I'll describe how I would work around this scenario.

---

If there exist any issues referencing the Silverlight assembly, consider building two projects as follows:

Project #1 would be your Silverlight library, and should contain all the source files you want to use on the client.

Project #2 would be your Windows Service. Instead of including source files directly, use the "Add Existing Item", find the original source file in project #1, then (and this is the magic), drop down the Add button to choose, instead, choose "Add as Link".

By including the source file as a link, you retain the ability to maintain your source code in one location, but add the ability to compile your code for multiple frameworks. As long as the code relies on assemblies available in both the Silverlight framework and the full .NET framework, then you're money.

---

Now, regardless of whether you choose a multi-project approach, know that domain context classes have additional constructors that allow you to specify contextual information, such as the URL, for the corresponding domain service. I use the following code in one application to construct a domain context for a domain service that provides personnel data:

var context = new PersonnelDomainContext(
    new Uri(ConfigurationManager.AppSettings["PersonnelServiceUrl"]))

In this case, the URL looks something like:

http://website-url/Services/Hyphenated-Namespace-PersonnelDomainService.svc

Of course, when writing a Windows Service, nothing is stopping you from referencing the server-side domain service (not context) assembly directly. With the domain service in hand, you can instantiate a service instance without all the additional configuration and without the additional network XML payload. There are trade-offs to this approach, such as forfeiting centralized configuration management (such as connection strings), but depending on your circumstances, you may find the trade-offs to be worth it.

Happy coding!

---

Have you considered using fork-reuse? Take a look at:

http://sharednow.blogspot.com/2011/05/its-not-just-reuse.html