Silverlight and N Tier Architecture

Ryan van der Kooy asks:

"I've been beginning to try to find out how a good architecture will work using silverlight 2.0.  I've read that Silverlight 2.0 could possible offer a 6 tier design.  However, having a bll in your silverlight app could possibly be exposed by anyone decompiling dlls in the client bin.  Is this true?

I've also thought about how Business Objects will work in an app when they would (for the most part) be built, then serialized to be passed through a webservice.  Perhaps i'm looking waaaayy to deep into it.  Perhaps a simple client/server model will be best for a silverlight app?  DAL connected directed Silverlight through a webservice? " 

Sliverlight 2.0 applications should be "service oriented" applications. The fact that an application calls a web service does not make it service oriented. You should never have a business logic dll in a Silverlight application. Instead, expose business services on your web server. Business services expose the logical operations that your application is capable of performing... remember, the logical operations, not the physical operations (ie. PlaceOrder, not CreateOrder). These operations many times contain many physical operations like Create Order, Create Line Item, Send Confirmation Email, etc., but leave these details to your service. Generally, this will mean that your clients are telling you what to do, but not how to do it. By not having your application explicitly request that each minor step in the order placement process is performed, you are free to make fairly large changes in how you process orders without updating the client.

[1] http://weblogs.asp.net/rvanderkooy/archive/2008/03/04/silverlight-n-tier-architecture.aspx

2 Comments

  • Would you care to give some more comments regarding "You should never have a business logic dll in a Silverlight application". Is it really that obvious why this is true?
    I you compare building a standard desktop app with an Silverlight application using Astoria it seems they are pretty similiar. If so, you would certainly need som order,orderitem, product etc. objects with built in business logic, or am I getting this completly wrong?

  • You would not have a business logic DLL on the client side, because business logic lives behind your services. You would have some kind of DLL that contained proxy objects which communicate with your services (like the kind of objects that get generated by "Add Web Reference"), but the service implementation would use the real business logic dlls.

Comments have been disabled for this content.