CSC/ECE 517 Spring 2025 - E2525 Reimplement review mapping controller.rb

From Expertiza_Wiki
Jump to navigation Jump to search

Introduction

This project aims to re-implement the ReviewMappingController as part of a backend modernization effort. The goal is to build a clean, efficient, and maintainable version of the controller from scratch in the reimplementation-back-end repository, following Rails best practices and RESTful design principles. The new controller will be responsible only for handling HTTP requests such as creating, assigning, and deleting review mappings, while delegating all business logic to models, or helper modules. This approach will ensure better code organization, improved testability, and easier long-term maintenance. It ensures that each layer of the application handles a specific task: the controller manages request handling, the models encapsulate data-related logic, and service objects take care of complex workflows or operations. Overall, this reimplementation aims to establish a solid foundation for the controller that aligns with modern Rails development standards and supports the long-term sustainability of the Expertiza platform.

Requirements

  • Reimplement the ReviewMappingController in the reimplementation-back-end repository without reusing legacy code.
  • Ensure the controller only handles routing, parameter validation, and delegation of actions.
  • Migrate business logic to models, service objects, or helper modules.
  • Use polymorphic or strategy design patterns to manage different review mapping types.
  • Provide thorough unit and integration tests along with inline documentation.

Existing Issues

  • ReviewMappingController contains highly coupled and outdated code that mixes business logic with request handling.
  • Hardcoded parameters reduce flexibility and adaptability across different environments.
  • Inconsistent validation and minimal error handling lead to unclear user feedback.
  • Several methods are overly long and difficult to maintain.

Design / Proposed Solution

The ReviewMappingController is responsible for managing the creation, assignment, and deletion of review mappings among participants in an assignment. Following reimplementation-back-end best practices, the controller strictly handles HTTP request routing, parameter validation, and delegates business logic to model methods. It interacts with models such as ReviewResponseMap, MetareviewResponseMap, and SelfReviewResponseMap, which maintain reviewer-reviewee relationships. Operations like dynamic reviewer assignment, metareviewer assignment, and self-review initiation are implemented as model methods to ensure a thin controller and a fat model design. Helper modules like ReviewMappingHelper provide small reusable utility methods, promoting modularity, extensibility, and maintainability while adhering to Rails conventions and RESTful principles.

Controller Diagram

Methods / API Calls

Method HTTP Verb Route Purpose
list_mappings GET /review_mapping List all mappings for an assignment
create_mapping POST /review_mapping Create a new reviewer → reviewee mapping
assign_reviewer_dynamically POST /review_mapping/assign_reviewer_dynamically Dynamically assign a reviewer to a team
assign_metareviewer_dynamically POST /review_mapping/assign_metareviewer_dynamically Dynamically assign a metareviewer to a review
start_self_review POST /review_mapping/start_self_review Initiate a self-review for a participant
automatic_review_mapping POST /review_mapping/automatic_review_mapping Automatically distribute reviewers across teams
delete_mapping DELETE /review_mapping/:id Delete a review mapping
unsubmit_review POST /review_mapping/unsubmit_review Unsubmit a submitted review

Pattern(s)

Strategy
The Strategy Pattern is a behavioral design pattern that enables selecting an algorithm’s behavior at runtime by defining a family of algorithms, encapsulating each one, and making them interchangeable, thus promoting flexibility and adherence to the Open/Closed Principle. In the context of ReviewMappingControlle, which handles multiple types of review mappings such as reviewer assignments, meta-reviews, and self-reviews—each with distinct business logic—the Strategy Pattern allows each mapping type to be implemented as a separate strategy class following a common interface. The controller simply delegates the task to the appropriate strategy based on the mapping type in the request, thereby abstracting complex decision-making logic away from the controller itself. This promotes separation of concerns, enhances extensibility by enabling the addition of new mapping types without altering existing code, eliminates repetitive conditional statements, and encourages a modular design that is easier to test, maintain, and understand.

SOLID Principle(s)

Open and Closed Principle
The Open/Closed Principle (OCP) is one of the SOLID principles of object-oriented design and states that software entities such as classes, modules, and functions should be open for extension but closed for modification. This means that the behavior of a system can be extended without altering its existing source code, promoting stability and reducing the risk of introducing bugs when requirements evolve. In the context of ReviewMappingController, applying OCP ensures that new review mapping types (such as peer-reviews, meta-reviews, or future additions) can be supported by introducing new strategy or service classes, rather than modifying the controller or existing logic. This principle encourages the use of abstraction, interfaces, and polymorphism to allow new behaviors to be added seamlessly. By adhering to OCP, the controller remains resilient to change, promoting a modular and maintainable architecture where existing tested code remains untouched, and new functionality is integrated through clearly defined extension points.

Single Responsibility Principle
The Single Responsibility Principle (SRP) is a fundamental concept in the SOLID principles of object-oriented design and states that a class or module should have only one reason to change, meaning it should only be responsible for one specific part of the system’s functionality. In the context of the ReviewMappingController, SRP implies that the controller should focus solely on handling HTTP requests—such as receiving input, validating parameters, and returning appropriate responses—while delegating all business logic (like reviewer assignment algorithms or validation checks) to separate service classes, models, or helper modules. This separation improves modularity, readability, and testability, as each component has a clearly defined role. Adhering to SRP reduces the complexity of individual components, makes the code easier to maintain, and ensures that changes in one area (e.g., business logic) do not inadvertently affect another (e.g., request routing), resulting in a more robust and scalable architecture.

Implementation

The ReviewMappingController will be reimplemented from scratch, focusing solely on handling HTTP requests while delegating business logic to service objects, models, and helper modules. We will implement strong parameters for secure data handling, ensuring only valid and required fields are processed. The controller will use Strategy Pattern to modularly handle different review mapping types (e.g., reviewer assignments, meta-reviews, self-reviews), with each type having its own dedicated service class. This ensures that new mapping types can be added without modifying the existing controller code, aligning with the Open/Closed Principle. We will also ensure adherence to the Single Responsibility Principle by moving complex review mapping logic, such as dynamic reviewer assignment and validation algorithms, into service classes and helper modules. Flash messages and error handling will be standardized to provide consistent feedback to the user. Additionally, we will maintain a clean and organized codebase by decomposing lengthy methods into smaller, manageable units and removing any redundant or dead code. This modular design will ensure a maintainable, flexible, and extensible controller implementation.

Testing Plan

A comprehensive testing strategy will be implemented to ensure the functionality, security, and performance of the ReviewMappingController. Unit tests will be written for the service objects and helper modules to verify that business logic, such as reviewer assignment and mapping validation, is functioning correctly. We will write integration tests for the controller to ensure that all CRUD operations (create, read, update, delete) are handled correctly, with appropriate success and error messages returned for different scenarios. Tests will also cover edge cases, such as invalid input and unsuccessful review mapping creation.Additionally, performance testing will be carried out to ensure that the controller can handle a large number of requests without degradation. By following a test-driven development (TDD) approach, we will ensure that the controller and its associated services are reliable, secure, and performant.

Team Information

Mentor

  • Anish Toorpu

Team Members

  • Niharika Maruvanahalli Suresh
  • Cristian Salitre
  • Aditya Anand Kulkarni

References

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2025_-_E2525_Reimplement_review_mapping_controller.rb&oldid=163750"