Distributing Business Logic Across Tiers in MemberJunction

MemberJunction’s architecture is designed to facilitate the distribution of business logic across different layers of an application, particularly between the client and server sides. This is a simplified description, the real power comes in that the business logic can be distributed automatically across any number of tiers in a complex n-tier application deployment. This approach is pivotal in creating a more efficient, responsive, and user-friendly application.

The Need for Logic Distribution

In modern applications, it’s often necessary to execute business logic in various environments, most commonly:

• API Layer: The server or API layer is the traditional location for executing business logic, ensuring data integrity and enforcing business rules before the data reaches the database.
• User Interface Layer: However, there’s also a need to execute certain logic on the client side, such as in web browsers or mobile apps. This can improve the user experience by providing immediate feedback and reducing the need for server round trips.

Benefits of Logic Distribution

Distributing business logic across client and server layers offers several advantages:

• Improved Performance: By executing validation and other logic on the client side, applications can reduce server load and network latency, providing a faster and more responsive experience for the user while also reducing the cost of maintaining and managing server infrastructure.
• Consistency and Maintenance: Maintaining the same logic on both client and server sides ensures consistency across the application. It also simplifies maintenance, as the same logic is used in both environments.

Execution of Business Logic in MemberJunction

MemberJunction addresses the challenge of logic distribution through its flexible architecture:

• Executing on Both Sides: MemberJunction allows the same business logic to be executed on both the server and client sides. By using TypeScript, a portable language and executing it in a way that is tier-independent through the MJ Provider Architecture, your code can run everywhere without modification. This is particularly useful for tasks like data validation, where immediate feedback on the client side can enhance the user experience.
• Provider Architecture: The MJ architecture utilizes a provider architecture, which abstracts the business logic from its execution environment. This means the same business logic can run seamlessly in different contexts, whether it’s on a server, a web browser, or a mobile app.

Example: Validation Logic

Consider a validation scenario where an input on a form needs to be checked against certain criteria. A common scenario might include conditional validation. An example could be a checkbox on a form. Whenever that checkbox is checked, another field becomes required, but if the checkbox is unchecked, the other field is not required (and also not enabled/visible).

Normally this would require writing code separately within the API (to ultimately enforce it) and in the UI (to provide better user responsiveness).

📘

With MemberJunction’s approach you simply sub-class the strongly-typed, generated sub-class and implement your validation logic.

MemberJunction will automatically execute your code on any tier where the custom library resides.