As architects, designers, and developers create the first wave of Silverlight applications, one thing has become apparent. We need to give some thought to how the use of Silverlight in the presentation layer changes the way we architect, design and code applications.  Some popular patterns that that have served us well in the past need to be revisited.

I thought that I’d use this forum to highlight some of the challenges that many early Silverlight users face, and invite comments or suggestions from people working with or thinking about the same challenges.

This post is related specifically to the topic of code reuse and redundancy. In future postings, I hope to take up other similar topics. 

With smart development tools and knowledge of best practices and enterprise design patterns, we seem to have been quite successful in maximizing reusability and minimizing redundancies in code. So, why is code reuse and redundancy important again?

Two reasons –

1.       Silverlight applications cannot reference .NET class libraries. The same constraint applies to the reverse -.NET applications cannot reference Silverlight applications.

2.       The use of Silverlight often requires developers to find the right balance between code reuse, maintainability and performance.

Let’s look these two points in more details.

Silverlight applications cannot reference .NET class libraries. The same constraint applies in reverse -.NET applications cannot reference Silverlight applications.
This basically rules out the development of class libraries with common reusable logic to be used by both .NET and Silverlight applications.
If a developer coded common math routines that need to be accessed by a Slverlight application and a .NET application, they may end up duplicating the exact same code in two different class libraries.
Let’s take a more realistic scenario where a developer creates aspx pages with embedded Silverlight applications. Now suppose that several Silverlight controls and aspx pages (read code behind) need to access the same WCF service. It would be ideal if the developer could create one service agent class that contains the necessary web reference, the code to invoke the service, and a common API that can be used by all Silverlight applications/ controls and .NET applications that need to consume the Web service. This would ensure that Web service reference and the code to invoke the service exists in only one place.
However, because of the fact that Silverlight  and .NET assemblies cannot reference each other,   developers may have to develop two service agents with the exact same code and Web service references.
Taking this scenario forward, assume that we need entity translators to translate the types exposed by the proxy to business entities used internally in the Silverlight and ASP.NET applications. Again we will need to develop different translators with identical code.

So, what’s the solution? Using source control features to link class files in different Visual Studio projects? Creating scripts that copy/ synchronize different class files?  Would you write a slightly intelligent script that would change the namespaces appropriately. These all work to some extent, but are far from an ideal solution. Me? For now, I’m living with duplicate code in different class files.

 

Code Reuse vs. Performance and Maintainability

Consider a Web application with a Silverlight control that access WCF services.  There are several ways of designing this application. I think the two design options that most of us will consider are:

a.       Encapsulate the presentation logic as well as logic for accessing Web service in the Silverlight application.  The business logic and business entities, if they exist, will also be part of the same Silverlight assembly. 

b.      Encapsulate the presentation logic in a Silverlight application. Create separate Silverlight class libraries for business components, business entities, and service agents. This approach allows common logic to be used by more than one Silverlight application.

Both approaches have their advantages and disadvantages.
Approach a provides better performance, a much leaner Silverlight application, but limited code reuse. Another Silverlight application in the same Web application may contain the same Web service reference an entity definitions.

Approach b provides a layered application architecture and allows code reuse. However, it increases the number of the in-package and/or on-demand assemblies that need to be downloaded by the user’s browser. Additionally, some of these assemblies may contain code that is not used the executing Silverlight application, e.g. a service agent class that calls a Web service used by a Silverlight application or control on a different page.

 An important point to note here is that if we applied something similar to approach b to an ASP.NET application, the common assemblies would live on the Web server or application server depending on how it was deployed. They would never be a  part of any discussion related to page size or internet bandwidth of end-users.

When choosing between approaches a and b (and others), we need to consider the following very carefully:

-          What is the right balance between code reuse,  performance, and maintainability?

-          Should we introduce layered architecture and object oriented design concepts in Silverlight applications with the same rigor as we do while developing server components, just because the platform allows it?

After writing this post, I realize that it contains more questions than answers. Actually, it contains no answers. But like I said, the purpose of this post is to invite comments and views on this topic from readers.

When it comes to class libraries, it's not very hard to target multiple .NET-based platforms using a single set of source files.  I've been doing it for years with a large codebase, and the situation is really not that changed with Silverlight entering the picture.  As long as most of your code meets the least common denominator set of functionality offered by the platforms you want to support, it seems like a waste to duplicate source files.  You can make up some differences by using preprocessor directives or compatibility layers / platform independent replacements for services only provided on one platform.

By the way, you don't need to rely on any special tools or tricks to accomplish this.  Just put your project files for the different platforms in the same directory as the shared source files, and have each project reference that same set of shared source files.  (Individual projects may of course reference some non-shared source files as well.)  You can even put all of the projects in the same solution and build your code for all of your supported platforms at once.  Visual Studio has several nice features that help support this style of development: Project->Show All Files + right click on file->include/exclude, the ability to unload/reload projects (a wonderful feature), pre/post build steps (in case you need to clear intermediate files, which you might), configuration management, and so on.

These are all good questions. I also asked the question about source code reuse somewhere else. What I really like is to have an option or an automatic nant task to compile the  same project in .Net or Silverlight at will. Thus I share files at project level instead of the source code level.

The second question is really tricky regarding the layered architecture. I would prefer the layered architecture, as it gives better performance over all (Scott Gu told me the same assemblies will only be downloaded once if it's used by many silverlight applications, not sure it's true or not.) It's just the first silverlight application got hit badly. 

 And the codegenerator for WebService is bad, as it bloated the code. It probably will force me to create my own code generator.

I am also wondering what the performance will be if we have a lot segregated small assemblies for download. Theoretically we could have a single assembly for every dataobject. This could be one automatically, of course.

 Same problems we have for webservice call. We used to do this in the code behind:

if (x)

    CallServiceA

else

    d = CallServiceB + CallServiceC

end if

This may not be a good idea any more, since every call involves a lot overhead, and now silverlight does not allow synchronous calls. These kindof code sometimes does not belong to the businesslogic layer on the server side.

Live by a Better Code

http://www.raincoder.com

Equal parts art and science

Email: cguo@raincoder.com

pmalik:

Silverlight Assembly References

Silverlight applications cannot reference .NET class libraries. The same constraint applies in reverse -.NET applications cannot reference Silverlight applications.

Why don't you reference Silverlight Library in .NET application?  

(If this has answered your question, please click on "Mark as Answer" on this post. Thank you!)

Best Regards,
Michael Sync

Blog : http://michaelsync.net
Feed : http://michaelsync.net/feed

Hello, one thing to keep in mind is that Silverlight and desktop CLR are two different platforms. Think you have a .NET service and a Java client. There's no way to reuse the .NET assembly and Java package across platforms. One good aspect of Silverlight is its programming model is similar to desktop CLR. Many times the code are exactly the same. So you can reuse code, but not assembly.

To reuse the source code, in the "Solution Explorer", in one of your project, add an existing item. In the "Add Existing Item" dialog, select a file. Look at the "Add" Button, and you'll find a little arrow on the right side. Click the arrow, and you'll see a popup menu. In the Popup menu, there's an "Add as Link" option. By choosing this option, Visual Studio will link the file to the original project rather than make a copy, and all modifications you do in one project will automatically be reflected in another project.

Regarding to the second concern, I think business logic should be put on the server. You can have many web services, one for each business logic unit. Silverlight works best with the service oriented architecture. SOA is about exposing business process as services so they can be reused by various client applications or other services. Yes, the reuse is in the service level, not code level. I suggest you to read some SOA articles. We (Microsoft) is an industry leader in SOA. Please check out our SOA solutions at http://www.microsoft.com/soa/. IBM is another industry leader in SOA. You can have a look at their web site at http://www-306.ibm.com/software/solutions/soa/.

shanaolanxing - I'll transfer to the Windows Azure team, and will have limited time to participate in the Silverlight forum. Apologize if I don't answer your questions in time.