Thursday, July 17, 2008

Generic and Concrete: Is this grease and water?

When developing software: can the application architecture be generic, and at the same time contain concrete business logic? Would this design be analogous to grease and water?

Designing a flexible enterprise application requires both, so the answer should obviously be no: generic architecture and concrete business logic are not like grease and water., but somehow these concepts often get treated like they are.

Based upon that idea, here are some guidelines for making sure the application architecture is generic while still containing the concrete business logic successful applications require:

Use a application framework

Using a framework for your application pretty much always makes sense. Unless your developing a basic button to database application you will want to seperate the logical layers of the application, while providing a basic set of conceptual building blocks.

These conceptual building blocks are the generic portion of your application. They create the foundation on which to build your concrete business layer.

Build state into your framework

So many times people make a really common mistake in their pursuit of a business application's library.

They forget that the business layer needs to know the state of the object: Does the object represent a new set of data? Is this data already in the database, and needs to be updated? Does this object persist data at all?

All important questions, right? No one would ever make this mistake.

Has anyone seen this type of logic in a SQL proc before?
IF EXISTS (SELECT * FROM dbo.Person WHERE PersonID = @PersonID)
UPDATE dbo.Person
SET [First] = @First
,Middle = @Middle
,[Last] = @Last
WHERE PersonID = @PersonID
INSERT INTO dbo.Person([First],Middle,[Last]) VALUES(@First, @Middle, @Last

Here, the developer moved the decision of the state of the data (and therefore the object that was the source of the data) to the stored procedure.

Why is state important to your business framework? And how does this keep my application architecture generic?

Future topics on the same subject:

Build business validation into your framework

Build security into your framework

Remember: Not all specific specific concepts can be generic entities

Make sure the framework follows the OOP paradigm

No comments: