As I understand in the 3-tier architecture, the presentation layer talks to business logic layer, which talks to data access layer. And, ideally, business layer knows nothing about presentation, and data access layer knows nothing about business layer. I want to write classes to do CRUD database work that are separate from the domain classes. For example, Foo is a domain class in business layer, and I want to write a PersistFoo class that takes Foo objects and CRUDs. My question is (somewhat theoretical?) which layer does PersistFoo go in? Logically, it belongs in the data layer to me. However, PersistFoo depends on Foo (e.g. it reads database and converts data to Foo objects and returns them). So, if PersistFoo is in the data layer, then it depends on the business layer, which violates that lower layers should not depend on higher layers.

1 Answer 1


There are a couple approaches you can take here, depending on the complexity of your application.

If it's a simple 3 tier application where your domain object map closely (or exactly) to your database table(s), then you can think of your domain object as cross cutting, meaning they can be put in their own assembly and shared across both the business and data access layers. If your application simply wants to do CRUD operations on Foo objects, why add unnecessary abstraction layers. Don't over engineer :) You'll still have the dependencies going down the stack (presentation -> service -> database) and not up.

Another possibility is to do something like I've done at my current job. We have a poorly designed legacy database where the data model is much different than the domain model. Some domain objects are sourced from multiple data objects. So what we do is we have both domain and data objects, and the business layer is the only layer that depends on both. Presentation layer depends on the domain objects, and the database layer depends on the data objects. There are translation services in the business layer.

  • Are you saying, in approach 1, if I was using Java, put the domain objects in their own package, which would be imported in business layer and data layer?
    – drg
    Commented Jan 6, 2017 at 19:47
  • Yep, that's exactly it.
    – jeff.eynon
    Commented Jan 6, 2017 at 19:58
  • You could create an anemic data entity class called FooData which would be the object shared between the domain and data layer. This way, FooBar could use a FooData object and send it to the data layer as well. The data layer won't really care where it came from.
    – JeffO
    Commented Jan 6, 2017 at 20:23
  • So FooData would be read-only, no methods. If so, I sometimes call that a "Transport Class"
    – drg
    Commented Jan 6, 2017 at 20:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.