I’m working on an application whi开发者_JAVA技巧ch has been designed using n-tire application architecture .The application was developed in the .NET platform utilizing C#,VB.NEt, Framework 3.5, Dataset, WCF, asp.net update panel, JavaScript ,Josn, 3rd Party tools. my current proposed layout is such
presentation layer -> Business Logic -> WCF -> DAL->Data access
The point Is: Is the above layout the right way to build SOA systems ?
As always, your advice is greatly appreciated
This depends on your definition, see Fowler's comments.
Generally, in order to get the most benefit from something SOA, you're services should be designed to be reusable by multiple consumers. This means placing your business logic "beneath" your WCF layer. Then you can have, for instance, a Silverlight client, a WPF client, etc. using the same services and business logic.
Change your scenario to:
Multiple Presentation Layers -> WCF -> Business Logic -> DAL-> Data access
Looks like it COULD be correct although I'd put WCF between your Pres and Biz layers too. Also, don't be afraid of having a non-linear path for your SOA architecture (i.e. having side services like an "EmailService" and "WeatherDataService" that come from the side of your N-Tier path. Obviously the WeatherDataService would come from the side of your DAL but the EmailService might come from the side of your Biz layer.
Some great links for you:
- Doing N-Tiers with WCF
- WCF and Datasets with N-Tiers
- N-Tier with WCF, MVC, and LINQ
Your services should be business operations, not data operations. A better version of your design would be: presentation layer -> WCF -> Business Logic -> Data access.
N-tier / layering is a pretty dated concept these days. It always broke down. Instaed, think of your software as a number if interacting services.
精彩评论