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)
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