Setting up a new project with both silverlight and .net

Shane posted on Friday, February 20, 2009

Greetings,

I'm creating a site and I'm suffering a bit from options overload and likely some misunderstandings in making some decisions about the architecture of my project.

Ultimately, I'd like to have a solution that I can deploy initially to a single web server backed by sql server but can easily be scaled out to use an application server when necessary.

I need to support both silverlight and regular .net UX. I'm having a little bit of trouble understanding the choices I have and need some advice about my current assumptions.

Currently, my thinking is to structure the solution like so:

MyApp.Business.Silverlight
MyApp.Business.NET
MyApp.Data
MyApp.Silverlight.TestApplication
MyApp.Web.Site
MyApp.Web.WCFPortal.NET
MyApp.Web.WCFPortal.Silverlight

Am I correct in thinking that I'll need two different WCF portals; one for silverlight and one for regular .net code, each on a different port and referencing csla dlls for silverlight and .net respectively? I'm assuming both should share a namespace and assembly name and the silverlight version would link to the business classes in the .net version.

I've been looking through the sample projects and running a few of them, but I'm just not clear on some of the choices.

I'd like to keep the WCF portals in their own web projects with different ports to support scaling in the future. I'm not sure if I should be using the object factory approach or...

Any advice would be appreicated.

Thanks!
Shane

RockfordLhotka replied on Saturday, February 21, 2009

There are a lot of options now, that's very true.

It is true that you need different endpoints for the .NET and SL data portal hosts on the server. You can put them in different virtual roots (web projects) or not as you choose - either way works from a technical perspective.

It is not true that they need different ports. They are just different endpoint names (like different web pages) and can co-exist in the same virtual root, under the same port, with no problem. In this case you'd just have two svc files and two service endpoints in your web.config.

The real issue for most people, I think, is that the SL data portal host has to be available to the SL clients, which may mean it is on a public web server. It is quite possible that your .NET users are internal, and so would probably access a data portal host inside your firewall. That seems like the most likely reason you'd have two app servers.

And even then you don't necessarily need two app servers. The SL data portal host machine can act as a "relay", simply routing all calls to the real app server.

This blog post should be helpful

http://www.lhotka.net/weblog/CSLALightDataPortalOptions.aspx