Skip to main content
Home Forums Silverlight Design Designing with Silverlight Architecture: where should the business logic go?
6 replies. Latest Post by rmcsharry on October 16, 2008.
(2)
DrGriff
Member
16 points
51 Posts
09-29-2008 10:37 AM |
If the web site is to be database driven, then you have the Silverlight "application" running in the browser and communicating with web services (WCF) to access the database.
Now, it seems to me that unlike "traditional" web applications, we now have two possible places for the business logic (model).
The first "location" is to build the business tier ("Model") directly on top of the data tier running on the Server and then to build a set of web-services on top of this. This is more familiar with traditional web servers. The problem with this approach is that there is a lot of CPU on the server and this could become a bottle neck.
The second "location" is to build this business logic all within the Silverlight application that is run in the browser. This has the advantage of taking much of the load off the server (the server now simply acts as a data server) but has the disadvantage of making the Silverlight application much larger (so, signficantly longer start-up times in the browser).
I guess it depends upon the size of the application, but does anyone have a view on what would be the "preferred" option?
Griff
rmcsharry
345 points
239 Posts
09-30-2008 3:23 PM |
This is a great question and a problem I too have been wrestling with. My reasoning goes like this:
1. The front-end is the presentation layer. Therefore all it should do is handle presentation.
2. Users hate waiting for downloads, therefore keep the silverlight download as small as possible. If it takes 5 mins to download some users will probably not even bother waiting for it to finish and surf on elsewhere. We live in a "i want it now" culture.
3. Servers are very powerful, and to some extent, quite scalable. If you get to the point where CPU is a problem, up the CUP's or scale-out. It's quite normal to have a database server and a web-server.
4. Initially it's probably best to put as much of the business logic as you can into the stored procedures. Your WCF services should call be calling the stored procedures and any other business logic that's not in the SP's can be on the web-server (even if that is the same box as the database server to begin with).
However, having said all that, I am currently reading about this, which seems to make a lot more sense:
http://www.lhotka.net/cslalight/Default.aspx
and the books too (C# Business Objects).
Hope this helps.
I would be interested to here other's thoughts on this also, since I'm no expert!
Regards,
Richard
Yi-Lun L...
All-Star
25052 points
2,747 Posts
10-01-2008 12:31 AM |
Hello, today there're two popular architectures for business solutions.
One is the traditional database oriented architecture, as you mentioned. In this architecture, applications are isolated. You create a data access layer, a business logic layer, and a presentation layer, only for the single application. They cannot be reused without extra work. Such solutions are generally easier to create because the architecture is simple, but it's quite difficult to be extended, and if you want to create another application that has some similar business logic, you'll have to do the whole process once again. Also your application is tied to the database. If in the future you need to use other kinds of data storage, such as a cloud service, you'll have to rebuild almost the whole solution. Finally, you're bound to a single technology. Different technologies cannot easily communicate with each other without standard based services. That's why today more and more orgnizations has moved toward SOA. But the traditional architecture will still live for a long time, because an SOA solution will generally take more efforts to create. So in a future version of Silverlight, we'll try to see whether it's possible or not to allow you to access database directly without invoking web services, or at least make the web service call transparent. But I can't assure you anything at this time. Today you can already get some of the behaviors with ADO.NET Data Service.
Another popular architecture is SOA, which we recommend you to take. In this architecture, you expose your business logics via services (web service is just one kind of service). Services are loosely coupled. A client application (such as Silverlight) can use any services it wants, and it can change to other services as it wishes. Thus when creating a service, you should understand that the service is not only for the application you're currently build. Other client applications will also use it. So a service looks more like an API. Think of the Silverlight API, you can use it in many many applications. It's impossible if when we design the API, we have a particular application in mind, and don't take other applications into account. From a client application's point of view, it doesn't know anything about the database. It gets all data from various services. A service may get data from a database, an xml file, or another service. The data accessing process is completely transparent to client applications.
The architecture is not limited to Silverlight. The client application can be an ASP.NET application, a WPF application, a Flex application, another web service (maybe written in Java), or anything. They can invoke the same service. So once you deployed a service, you can use it in any client application you like. From the long run, you'd better adopt SOA.
You don't need to concern about performance. Have a look at today's popular SOA solutions such as Live Search Maps and Google Earth. They're exactly built upon the SOA architecture. The web interface is just one client application. It's not special. Yet the client applications works very performant while serving such a large amount of data (a lot of images).
10-01-2008 5:34 PM |
Thanks for that Yi-Lun, I suspected SOA was the way to go, just wasn't too sure!
10-09-2008 4:46 AM |
Hi Shanaolanxing
I agree with your statement about SOA. However, I don't think that this is the complete answer.
WIth SOA (let's take the idea of web-services) then yes, they obviously need to have their own business logic built in. We might (say) have a client application that calls various web services in New York, London, Paris and Munich to get information on the most populat pop music songs. Well, each web-service would have to access some business logic to decide what exactly is a "pop" song and how many copies must have been sold to class it as "popular". However, these separate web-srevices have no idea what is going to happen to the data that they provide - what extra business logic will be applied.
Okay, now lets take the example of an eCommerce system. I think in someways that in some ways, SilverLight turns the whole paradigm on its head.
With a normal ASP.NET application, the "application" (if there is such an entity) really exists on the Server. The "application" sends data to the browser (eg a list of products) and the user identifies the products that they're interested in buying. The server then builds up a shopping basket (the browser has know knowledge of this "order" object) and passes more product categories back to the browser. Eventually, the user then tells the server that they're finished, and the server then processes the order and order lines (applying any budget/credit checks etc). In terms of the an Application utilising Data, you could consider that the server is utilising data provided by a browser (the browser/user is the SOA).
With a Silverlight application, the "application" can exist in the browser. It requests product catalogue information from the Server and builds up an order object in the Browser. When the user finishes, the budget and credit checks can be performed in the Browser (albeit with the necessary data provided by the Server) and if everything is okay, will then pass back the finalised order to the Server to log in the database and pass on to the back-office system. This significantly reduces the work load on the server by distributing the BL to the browser.
DotNetAd...
80 points
53 Posts
10-14-2008 8:32 AM |
This is a classic architecture problem. Unfortunately, any good architect knows that there is no such thing as "one architecture fits all". The truth is that there are always variations on patterns and best practices that need to be adapted specifically to the requirements of the project implementing that architecture.
I've built a LOT of n-tier web applications and I've seen virtually every tier split possibility you can think of (including the horribly bad ones). The most prevalent in the COM days was we had a VBScript/ASP front-end which invoked regular COM objects for the business logic. These would then invoke COM+ "reader/writer" services (one for reading, one for writing). In today's world where SOA is the current buzzword, you should try and figure out where the separation of concerns in your application lies.
Instead of thinking about your app in terms of services and tier splitting at the start... think about your app as if it was one big self-contained monolith. Figure out the functionality you need and the use cases that you need to support. Figure out the types of people that'll be using the application and more importantly, how they will be using it. From this "pre-design monolith", you get a very clear picture of what your app needs to do. You can then take scissors to your design and start separating out things that can operate in a loosely coupled fashion.
When you're done chopping... you need to make sure you're doing all of this with your particular domain in mind. What I find is that, more often than not, especially with Silverlight, you end up with certain kinds of business logic in the Silverlight app and certain kinds inside individual services. It becomes a somewhat blurry line between tiers, but in a true SOA environment, you don't have tiers, you just have non-overlapping responsibilities. When you look at the pieces of your app in this way, it doesn't bother you so much that some of those responsibilities belong inside Silverlight (either for performance or logistics reasons) and some of those belong inside services and yet others belong in the database (or whatever backing store you're using).
10-16-2008 3:44 PM |
DotNetAddict: What I find is that, more often than not, especially with Silverlight, you end up with certain kinds of business logic in the Silverlight app and certain kinds inside individual services. It becomes a somewhat blurry line between tiers, but in a true SOA environment, you don't have tiers, you just have non-overlapping responsibilities. When you look at the pieces of your app in this way, it doesn't bother you so much that some of those responsibilities belong inside Silverlight (either for performance or logistics reasons) and some of those belong inside services and yet others belong in the database (or whatever backing store you're using).
What I find is that, more often than not, especially with Silverlight, you end up with certain kinds of business logic in the Silverlight app and certain kinds inside individual services. It becomes a somewhat blurry line between tiers, but in a true SOA environment, you don't have tiers, you just have non-overlapping responsibilities. When you look at the pieces of your app in this way, it doesn't bother you so much that some of those responsibilities belong inside Silverlight (either for performance or logistics reasons) and some of those belong inside services and yet others belong in the database (or whatever backing store you're using).
Thanks for that DotNetAddict. I am finding you are right, and that the logic is getting split simply because of the different demands of the different users, and other considerations such as performance and maintainability etc.
Architecture: where should the business logic go?