At times, software development can be a complicated task, especially when developing enterprise-level systems with heavy load or critical functionality. It is because of this, that software architecture has become increasingly more important and refined. There are now so many types of software architectural models, that choosing the most appropriate solution is a skill in itself.
In this article, I would like to demonstrate two fairly generic architectures that I prefer to use for enterprise applications which require a decent amount of complexity and the flexibility to be easily maintained and updated in the future. There are of course pro’s and con’s to each of these architecture models, which we will discuss later in this article.
Both architectures take into account the following requirements:
- Logical seperation between functional purpose.
- Reuseable code.
- Flexible for maintenance/upgrades.
- Tiers are able to be distributed across several servers.
Objects as Actors
First, to clarify what I mean by “actors”: an actor as I am using it refers to the code that executes behavior. In the case of objects as actors, the behavior is derived from the objects (business entities). This architecture is a hybrid and borrows concepts from several official architectural patterns such as Layered Architecture and OOAD.
As you can see, the layers are split into four major areas; data access, business logic, presentation, and common/crosscut. In this case, the business logic layer contains both business logic (such as validation, computations, etc.) and business entities. Business entities become the main section of code that all interaction with the presentation layer derives from.
Logic and entities are tightly coupled because they are packaged together in the same layer. This is more closely related to object oriented design, where everything is object-centric. Now, many of you may have read the words “tightly coupled” and were turned off; but, choosing this architecture means you are deciding that if a business entity structure changes, the business logic will need to change as well. In most real-world cases, this is true, so tightly coupling is not as negative as you may expect.
Additionally in the architecture, there is are common assemblies that cross across all layers such as Utilities (ex: extension methods), Communication (such as between layers on multiple servers), and security.
The presentation layer could include any form of presentation platform such as Web, Windows, Mobile, Silverlight, etc. The primary point is that as much as possible, whichever presentation is in use, or if multiple presentations exist, all code interacts with a common point, the business entities.
Optionally, you can implement a services layer between the business and presentation layers to lean closer to a service-oriented architecture.
Presentation-Level Code Interaction Example
Let’s look at a short example of how you would interact with the entities from any layer above business logic. This code creates a “person” entity, assigns a first and last name in the constructor, and then saves the person to the database.
var person = new Person("John", "Smith");
person.Save();
Business Logic as Actors
The main differece between this architecture and “Objects as Actors” is that business entities are moved into the common crosscut section and treated more as data structures (thin vs. thick entities).
The interaction with these business entities occur through calls to the business logic layer directly instead of the entity. The advantages of this are that entities are lighter, changes in the structure do not have to be changed in the business tier, and the objects tend to conform better to WCF.
The drawbacks are that entities no longer have structured behavior of what they can and cannot do. You use another class (in the business logic layer) to define and execute the actiosn of business entities – the business logic actor.
Presentation-Level Code Interaction Example
Our same “person” example using the Business Logic Actor. The MembershipActor contains a list of possible functions to do with various membership-related logic (such as saving Person).
var person = new Person("John", "Smith");
var membershipActor = new MembershipActor();
membershipActor.SavePerson(person);
Additional Resources
While in the middle of writing this article, I came across the Application Architecture Guide 2.0 by Microsoft Patterns and Practices. You can download the complete guide from Codeplex here. Kudos to Microsoft for putting this out for free!
Closing Notes
Various points on architecture are debateable as to what is good or bad; mostly because it depends so heavily on the individual situation. However, I hope after you’ve read this article you will leave your feedback as to what you agree, and more importantly, disagree about the above architectural models.
Happy coding!
Nicholas Barger's Blog 