It is difficult to write about architecture because it’s such a subjective topic. The term itself means different things to different people. Given that Microsoft produces weak architectural guidance, I welcome any and all attempts to hone in on that illusive perfect architecture of a web application. Unfortunately, ASP.NET 3.5: Application Architecture and Design by Vivek Thakur falls short of my expectations.
Let’s step through the book.
Chapter 1. A good discussion of the steps involved in planning a web app life cycle: gatheting business requirements, planning and prototyping, development, release, and maintenance. The chapter also introduces the concepts of tiers (physical separation) and layers (logical separation) and goes on to suggest various
tier/layer combinations, e.g. single tier–two layer model, three tier model, etc.
The client’s browser is considered a tier of its own. I tend to disagree with this point of view.
Chapters 2 through 4 offer a somewhat deeper discussion of the various types of layering. This is also where I relived unpleasant flashbacks of string-concatenated T-SQL queries, invoked right in code-behind of a web page.
I should note that Chapter 3 had a glimmer of hope with a rather brief discussion of Entity-Relationship diagrams and
even—gulp—UML. Bonus points: data access code shows proper use of the using keyword.
Chapter 4 surprised me with a silly code sample along the following lines:
namespace OMS.CodeTier.BL
{
public class Customer
{
public void Add()
{
CustomerDAL.AddCustomer (this);
}
}
}
Now guess what happens? CustomerDAL goes right back to Customer, thus creating a weird strongly-coupled relationship.
Again, Chapter 4 throws another surprise by listing a class which exposes public fields instead of properties—a grievous sin in the .NET land—and calls them “public variables.” There’s some nomenclature cleanup begging to happen.
namespace 5Tier.Common
{
public System.String Address = null;
// … other public “variables”
}
Chapter 5 is a humble, yet hopelessly outdated overview of ASP.NET MVC Preview 5. The chapter is so short that I don’t know if one can learn anything from it.
ASP.NET itself doesn’t yield well to the Model-View-Controller pattern since the View and Controller are almost inseparable by design. Hence, I suppose, an almost mandatory mention of the MVC framework.
Design Patters, Chapter 6—my favorite subject. Folks, seriously, how difficult is it to “get” the Singleton pattern? How many times has it been discussed that locking on a type is a no-no? And I was taken aback by this explanation:
“We may need to pass an instance of [the singleton in question] class to some other method, but with static classes we cannot do so.”
So the singleton is sealed and it can be passed around. Now that’s a novel idea!
The Factory pattern is accompanied by another great explanation:
“Why do we need this design pattern? Change is one thing that we cannot avoid in software development. [… more on change …] The factory design helps us make our applications “change-friendly.”
Really, that’s what Factory is about? It’s about change? Hell, “yes we can!” So you can form an opinion of your own, here’s the implementation of the said Factory:
public class ProductFactory
{
public IProduct CreateProduct (string productType)
{
IProduct product = null;
switch (productType)
{
case "BeautyProduct" :
product = new BeautyProduct();
break;
case "ElectronicProduct" :
product = new ElectronicProduct;
break;
case "FoodProduct" :
product = new FoodProduct ();
break;
default: break;
}
return product;
}
}
Magic strings, um-hm, how much I dislike them.
Chapter 7: SOA and WCF. The term SOA, or Service Oriented Architecture, is bleak because it means too many things to too many people. I fully agree with Michael Nygard that it’s time to rethink what SOA actually means.
Here’s the author’s definition of SOA:
”[…] An architectural approach aimed at making it easy to introduce new features into an existing system, share data with other applications for easier integration, and bring a faster Return On Investments (ROI) to the business processes.”
Sounds like something out of the Web Economy Bulls**t
Generator. That said, this chapter is too weak to be of any use. At best, it’s a two-page introduction to WCF, which does WCF no justice.
While we’re dissecting this chapter, here’s something I spotted:
CustomerCollection customers = new CustomerCollection ();
CustomerDTO[] customerArray;
// get all customers so set page length = -1 indicating full load
int pageLength = -1;
Whoa, a magic number. Are we back in the C++ land?
Chapter 8: Database Design. Always a tricky subject. The chapter has a brief discussion of data integrity, normalization and a few other essentials. But then the author goes on to create a data model in Vizio with the idea of creating a DDL script right from Vizio itself. I think this is a seriously misguided approach, but it’s your right to disagree.
Chapter 9 is about globalization and localization. I don’t understand why this chapter was included. Localization is not new to ASP.NET, and the chapter is too short to cover such a broad topic.
Proofreading and technical review
With three technical reviewers on board, I expected better quality of content. I’m not sure whether misconceptions and inaccuracies where pointed out but ignored by the author and publisher. I had this happen to me on this project.
The book could also benefit from more diligent proofreading. As to
downloading source code, the provided link doesn’t work.
Conclusion
The field for discussing proper architecture of ASP.NET applications is wide open, and yet this book falls on its face. It’s too brief on technical and misguided on conceptual content. What was the point of writing it?
A special thank you to the fine folks at Packt Publishing for providing this review copy free of charge.
