2

I am developing software where each action in my entities need create tasks that will be execute in my infrastructure. When I create a task it is only records in the database. Afterwards, a windows service will execute it.

Actually, I use a Service and my Entities are Anemic, then when I change the state of my entity I also create my tasks to infrastructure.

    public void CreateMachine(string name){
      var machine = new Machine(){
                          Name = name,
                          Status = Status.Releasing;
};
      var tasks = new List<Task>(){
                   new Task("CreateMachine", machine.Name),                       //infrastructure task
                   new Task("ChangeMachineSize", machine.Name, machine.Foo),      //infrastructure task
                   new Task("ActivateMachine", machine.Bar),                      //infrastructure task  
                   new Task("SetMachineEntityStatusToReleased", machine.Name)     //business task (go to my database)
      _db.Task.Add(tasks);
      _db.Msachine.Update(machine);
      _db.SaveChanges();
     }
   }

But I want use rich domain, because my services are getting too complex.

    Public Class Machine{

        public Machine(string name)
        {  
          Name = name; 
          Status = Status.Releasing;
          //Can I Create Tasks for create machine here?
        }

        public void Stop(){
          Status = Status.Releasing
          //Can I create Tasks for stop machine here?
        }


        [Required]
        [StringLength(50)]
        public string Name { get; set; }

        public Status Status { get; protected set; }   
}

Is there a design pattern or best practice for this design? I am violating the Single Responsibility Principle if I add the task creation inside my entity?

1

Publisher/Subscriber, also known as Observer comes to mind. A Task factory can subscribe to status changes published by your Entity and create the Task instances as dictated by the change in status of the Entity.

  • I have not thought about use the observer pattern because I thought would still anemic. Furthermore, I tried to make the example simple but, actually, for create a task I use many properties of my Entity. e.g. new Task("description", entity.PropertyA, entity.PropertyB, entity.PropertyC); – Fernando Mondo Jun 28 '14 at 0:47
  • Whether your classes are anemic has nothing to do with using or not using Observer. Furthermore the Observer pattern is not restricted to passing along just "simple" parameters. The observed can pass along anything you need to the observer. So you could simply pass along the Entity instance that was changed and the observer can pick whatever it needs. – Marjan Venema Jun 28 '14 at 10:16
  • 1
    Perhaps your confusion stems from treating design patterns as code examples. A design pattern may have a code example to explain it, but it is never limited to that example. Design patterns are much more than just code examples. Design patterns are ways of talking about code and talking about general solutions to common problems. It is up to the developer to apply a design pattern to his/her specific problem by amending the explanatory example to his/her specific case. – Marjan Venema Jun 28 '14 at 10:19
  • Oh and using observer would make your observer of the Entity certainly non-anemic... Your Entity class still may or may not be anemic, but the observer certainly won't. The desire not to have anemic classes is very good, but you should still not put code in a class just to make it non-anemic. The code to instantiate the Task indeed does not belong in Entity as it would introduce unwanted (and unwarranted) coupling. Any code added to Entity should be related to Entity. – Marjan Venema Jun 28 '14 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.