vendredi 11 novembre 2016

How can my DAO layer interact with the presentation layer?

I read the StackOverflow guidelines and looked for a design-specific SE site. If you feel this question is still too long or unclear, please let me know and I'll try again.

I maintain an N-tier line of business, winforms application with the following layer/design:

  • [WinForm Application]
  • [MVP-based Presentation Layer (CAB, specifically)]
  • [Service Layer]
  • [Data Access Layer]

The application integrates with different ERP/business systems which is handled at the DAO layer by use of ERP/business system specific implementations of DAO interfaces, for example:

public sealed class QBTransactionAssemblyBuildDAO : QBDAO, ITransactionAssemblyBuildDAO
public sealed class SAPTransactionAssemblyBuildDAO : SAPDABase, ITransactionAssemblyBuildDAO

For example, one business division may use the application integrated with QuickBooks. This will be configured in the app.config and a factory method will create the appropriate QB*DAO implementations at runtime. Likewise another division may use it integrated with SAP, the config file will support this and the factory will produce SAP*DAO implementations. The services can then use the DAOs while remaining ignorant of the underlying integrated system.

This all worked great and in fact the design has paid dividends as I've had to add additional integrated systems and record support. That all changed today when I ran into a situation where an integrated application's API did not support a task that all the other systems can support. I'm now in a situation where I need to support an exceptional flow and rather than update data in say, SAP I need to present a dialog to the user with the data for them to manually transcribe (OK, copy and paste) into the SAP application user interface.

If I adhere to my layer and object separation guidelines the first opportunity for me to branch my application flow is at the service layer as this layer is knowledgeable about which ERP/business applications are integrated. At the service layer I can receive the request to "RecognizeDelayedRevenue", get my reference to my concrete DAO object and ask it if it supports the operation (the latter part being new). If it returns negative I now have the design challenge of presenting a dialog to the user, including pre-processing the data it presents using methods that belong on the DAO objects.

My question: From a design standpoint, which is the bigger sin:

  1. Service layer attempts to create and show win32 dialogs, basically breaking the separate of business logic and presentation
  2. The DAO object accepts (i.e. claims to suport) the request and rather than executing against it's integrated system, it somehow presents a dialog to the user
  3. Bring integrated system knowledge down to the presenter level and handle the exception there.

Of course if you have an idea that I haven't mentioned, that would be very interesting as well! :)

Aucun commentaire:

Enregistrer un commentaire