Lookup Tables - Where to put in n-Tier Architecture

Question

I have a few lookup tables that I am in the process of plumbing through my app. These are tables that drive dropdowns on the website. They have no business logic, but they need to get from the database to the UI while following the architecture of the app.

The current architecture has a Data Layer, Business Layer, and Presentation Layer. All database calls are in the Data Layer (using Model objects and Repositories). The Business Layer calls to the Data Layer, and the BL objects transform the data layer objects. The Presentation Layer then calls the Business Layer and uses the Business Objects. (Basically UI -> Services -> Repositories)

I just see it as a waste to have to plumb this through the Business Layer when there is no business logic. I wouldn't mind add a Lookup layer, or Common layer to this architecture, but I don't know where it would fit in or how I would go incorporate in the current flow. Any ideas on how I could go about this would really help.

EDIT: I guess I would really like to know how to incorporate a Common Library in here so I can add the Lookups to that. Should the common library sit between the Business Layer and UI, or should it be a "replacement" for the business layer? Or do I even need a Common Library?

Answer 1

Without knowing anything about your achitecture...

I suggest using the existing BusinessLogicLayer and BusinessLogic.

It might seem redundant because there is no business logic for these lookup queries.

But, at least the code would be following existing conventions/approach.

And if in the future businesslogic or lookup conditions were introduced you wouldn't have to change the PresentationLayer.

Answer 2

You should plumb it through your business layer for consistency. The code in that layer may be very thin in the first iteration for your lookups.