Jan 27, 2009 at 9:20 PM
Edited Jan 27, 2009 at 9:50 PM
Probably a poor choice of pun ;) Prism effectively utilizes patterns such as Supervising Controller MVP and Separated Presentation. The point is more towards seeing Silverlight as a fat client than thin, and like patterns, architectures should twist
and turn with the times.
With new and emerging technologies we have to continually revise and twist existing patterns
+ MVC -> MVP
+ ASP.NET MVC (Model2) from MVC
+ Presentation Model from MVC/Application Model.
Enter stage left Prism (aka CompositeWPF); permitting us to create fat clients on client side with the language we love so much - .NET.
The Presentation -> WCF -> Service Layer -> BLL -> DAL meets conventional programming needs but not for Prism. With Prism, modules are in different assemblies (which can be loaded dynamically). To use Silverlight as a simple (but elegant) UI
is a waste of client processing power resulting in unnecessary round trips - much of the application business logic can be in our Prism applications keeping our WCF services more generic and reusable across multiple applications, e.g., an Employee service
that knows how to get data from numerous corporate application databases and resources such as ADS.
What became problematic on a recent sprint was the addition of our first module's Web Service. A problem because there is no SvcUtil.exe for Silverlight (yet) and we are tied to L2S so we are forced to go with "Add Web Service" and as such we can
only reference our entities from our data layer (yes, we have a IBLL->IDataProvider in our silverlight module). Not to mention it's configuration file; this file coupled with the Website configuration file and the requirement to give the main assembly a
copy of the ServiceReferences.ClientConfig (Prism V2 Drop 8) which results in three configurations to maintain for a simple, single module application; this application will grow into a multitude of modules.
Some may think that three configuration files in itself doesn't seem so bad, but wait until you have to move them through a cycle of Development, Staging and Production servers. With every new module that accesses WCF Services comes additional configuration
files to maintain.
In the absence of an authoritative source and guidance (if it's out there I can't find it) the solution I'm toying with is pretty basic - when dealing with a fat client we're taught that you should have a pattern (PresentationModel, MVP, etc) that consumes
a reusable service - so it starts to look like this:
Presenter -> IService -> IBLL -> IDataProvider ~~~ WCF -> Service layer -> BLL -> DAL
Where the IService, IBLL and IDataProvider are configured in the application's Unity configuration section. Unfortunately with "Add Web Reference" we can only reference our entities from the implementation of our IDataProvider so I'm researching
the fastest method to project the results into a Shared library entities; this way our IService and IBLL are oblivious (as they should be) to the data object model - for example if I want to have my IDataProvider dynamically set to an implementation that operates
from an Isolated Storage data file if available.
Any guidance from the gurus on this matter would be appreciated.