mardi 5 juin 2018

Design pattern and database transaction

In one of the module of our project there are multiple related objects. Here are few of them and the relationships

  1. Project
  2. Discussions (Related to project. A project must have at least one discussion, 1-M relation)
  3. Surveys (Each discussion can have multiple Surveys. Surveys can be added later on, 0-M relation)
  4. Questions (Surveys can have questions One survey must have at least one question, 1-M relation)
  5. Expected Attendees (A project can have expected attendees, 0-M relation)

There are some other objects as well related to this scenario which I did not included here. In the time of creating a new project entire data needs to be saved in one go. Later on user may add other elements (discussion, surveys etc.) in an existing record.

In Data layer and business layer I created classes for each and every objects (Project, Discussion, Surveys, Question and Attendee). Since in the time of creating a new project few of actions (Survay save, Expected Attendee save etc.) are optional so we are thinking of Decorator pattern to save a project.

Now I have two questions

  1. Should we implement decorator pattern? Or there is any other pattern which address this situation better
  2. We have to implement the patter in business logic layer. In that case how can I implement transaction? This is a key problem when we are trying to implement any design pattern.

Aucun commentaire:

Enregistrer un commentaire