0

We follow 3-tier architecture, where we have presentation layer, business logic layer (Managers) and Data Access Layer. There are few processes that involves multiple entities which are controlled by different BLL classes (we refer to BLL classes as managers). Can we have one Manager class interacting horizontally with another Manager class. Wanted to know the opinion of the community, as just relying on Manager-DAL flow is creating a lot of code duplication.

voldegaur
  • 194
  • 2
  • 12

1 Answers1

1

I don't see anything particularly wrong with that also this happens more often than you might expect. In a layered client application for example, within the data layer you'll usually find a class that speaks to a framework / platform specific cache (usually it writes to the HD). Since the framework and data layers are on the same low abstraction level, it is fine for them communicate without having an architectural break.

The main thing that should be avoided is a dependency direction from the more abstract layers (entity / domain / business layer) to the less abstract layers (data or presentation layers).

Martin Nowosad
  • 791
  • 8
  • 15
  • I would also add that cross interaction is potentially a bad thing for the actors on the same level, for instance, manager A calls manager B which calls manager A. As it makes more difficult to hold in mind control flow, which leads to bugs and data races sometimes. – cassandrad Aug 16 '21 at 11:46
  • 1
    Domain to domain object interaction is complete okay. However, if all you have are "Manager" classes, or Handler classes,.then that means you don't really have a domain model – Mustehssun Iqbal Aug 21 '21 at 07:36
  • You probably have a variant of a transaction script in which Managers are executing procedurally. And now you're spotting some reuse among the managers. Just make sure that the interaction between Managers is meaningful. Maybe breaking the Manager into several different domain objects will be a great idea - and only using the Manager to expose those group of objects' functionality. Manager classes should be thin..if they are handling more than one responsibility, that should give you a starting point to refactor the design. – Mustehssun Iqbal Aug 21 '21 at 07:39
  • 1
    Also I would like to add, what is the relationship between the two interacting Managers? Is it an interaction in the business domain? For example, a light bulb is connected to a switch in an electric circuit domain. Hence my LightBulb entity should have a relationship with my SwitchEntity via a Circuit connector entity But if my SwitchManager class has a dependency on LightBulb class just because somewhere in SwitchBulbClass, there is a line of code that invokes LightBulb class, that is a wrong abstraction. It wouldn't scale well and would propagate problems to other layers as well. – Mustehssun Iqbal Aug 21 '21 at 07:43