Is a Hybrid of 2 and 3 Tier Architecture recommended

Question

Hi,

I am making a web application that takes various business rules as inputs and stores them in the database. This is done using a 3-Tier Architecture.

After that I have to use ALL these business rules in a single operation, and so I am writing the business logic for this part in Stored Procedure and am calling it from the UI making it 2-Tier.

Since this is a rare situation where all the data (which is a considerable amount - the SP itself takes about 6 min to process) is needed for a single operation, and it makes little sense to me to fetch all the data as objects into the BLL just for the sake of maintaining architectural integrity. Also the logic in the SP is iterative and so all the data will need to be maintained at the BLL and cannot be fetched conditionally.

Please suggest me if I have the right approach or not.

Answer 1

Business logic belongs where it is most appropriate. If you have logic which is associated with data and which is only ever executed by a stored procedure then the database is the proper place to hold it.

Answer 2

@APC is correct, logic should live where it's most appropriate - and:

• The UI should still go through the BL layer to get to data, so that your application is consistently structured.
• If your going to have logic in different locations in the app (in order to meet certain requirements, like performance) you should clearly document what those governing factors are, and it should be easy for the developers that follow to work out.

Two options come to mind (regarding structure):

• One way to ensure the application is appropriately structured and clear is to isolate specific "heavy lifting" tasks by interface. Ideally all your data access should already be abstracted out by interfaces anyway, and these should be broken up into logical areas (see Interface Segregation Principle - ISP). So you could have a dedicated interface for specific data access needs: [BL] -> [IDataAccess] -> [Concrete Data Access]
• Another approach (but along a similar vein): instead of having the BL access these special data calls like a regular data access, include or inject it as BL.

How you do the second approach: Define an interface (in the BL layer) that will be used by other business objects: [BL Object] -> [ISpecialBusinessLogic] -> [Concrete Implementation]. The concrete business logic could be anything - but in your case it'll be a call to a special Data Access method / component where you do the "heavy-lifting".

When you implement you data access, you have the option of doing it all in a single class / component (that implements multiple interfaces) or separate classes / components that each implement a single interface.

Answer 3

I assume that other modules of your application also maintains 3-ties architecture. so for the shake of consistency and maintainability you should maintain 3-tier architecture.

Further, in future, if you need to apply some business logic on the data returned by your SP, that you will do in your BL.