Quantcast
Channel: Domain Driven Design in a Workflow-enabled MVC Application - Design Decision - Stack Overflow
Viewing all articles
Browse latest Browse all 2

Domain Driven Design in a Workflow-enabled MVC Application - Design Decision

$
0
0

I'm building an N-Tier MVC 4 Application that implements the Repository and UnitOfWork patterns as well as Domain Driven Design using an abstracted CommandProcessor layer that validates and executes my CommandModels.

I'm beginning to learn Workflow Foundation now and have added a workflow project that handles user registration. At the end of the workflow if everything went through, the workflow will execute the ApproveMembership CodeActivity:

public sealed class ApproveMembership : CodeActivity{    [RequiredArgument]    public InArgument<string> UserEmail { get; set; }    protected override void Execute(CodeActivityContext context)    {        IDatabaseFactory databaseFactory = new DatabaseFactory();        IUnitOfWork unitOfWork = new UnitOfWork(databaseFactory);        IUserRepository userRepository = new UserRepository(databaseFactory);        string userEmail = UserEmail.Get(context);        User user = userRepository.Get(u => u.Email == userEmail);        if (user != null)        {            user.Activated = true;            userRepository.Update(user);            unitOfWork.Commit();        }    }}

There is also a similar RemoveMembership activity that deletes the user after a certain time if he never validates.

My question is, does it make sense to handle this right inside my workflow? Or is the better approach to use Dependency Injection in the workflow to get a CommandBus that will handle processing 2 new, almost identical command models that I will have to create, along with Validation and Submission handlers for them? This is how it's done in my MVC AccountController.

    public class DeleteUserCommand : ICommand    {        public int UserId { get; set; }    }    public class ApproveUserCommand : ICommand    {        public int UserId { get; set; }    }    public sealed class RemoveMembership : CodeActivity    {        public InArgument<string> UserEmail { get; set; }        private readonly ICommandBus commandBus;        private readonly IUserRepository userRepository;        public RemoveMembership(ICommandBus commandBus, IUserRepository userRepository)        {            this.commandBus = commandBus;            this.userRepository = userRepository;        }        protected override void Execute(CodeActivityContext context)        {            string userEmail = UserEmail.Get(context);            User user = userRepository.Get(u => u.Email == userEmail);            if (user != null)            {                var command = new DeleteUserCommand                {                    UserId = user.UserId                };                IEnumerable<ValidationResult> errors = commandBus.Validate(command);                if (!errors.Any())                {                    commandBus.Submit(command);                }            }        }    }

Obviously it's a lot more code but is it good design?

I feel like I answered me own question writing this and I'm thinking the answer is YES. But would still like to hear a professional opinion.


Viewing all articles
Browse latest Browse all 2

Latest Images

Trending Articles



Latest Images

<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596344.js" async> </script>