Ehsan Ghanbari

Experience, DotNet, Solutions

Asp.net core razor pages with a simple command, query handler

I'm already working on a project and a challenging decision has been made to use asp.net core razor pages. Based on Microsoft definition:" ASP.NET Core Razor Pages is a page-focused framework for building dynamic, data-driven web sites with clean separation of concerns." I've found razor pages so cool so far as it's totally compatible with the architecture of the current project of mine. I'm using a simple command query (it's not CQRS) in this project. Once I shared another architectural pattern about Command and query over here. Take a deep look at the following simple base classes and interfaces:

 

 public interface ICommand<out TResult> { }

   public interface ICommandHandler<in TCommand, out TResult> where TCommand : 
   ICommand<TResult>
    {
        TResult Execute();
    }

    public class CommandResult
    {
        public bool Faild { get; set; }

        public string Message { get; set; }
     }

    public interface IQuery<out TResponse> { }

    public interface IQueryHandler<in TQuery, out TResponse> where TQuery :  
    Query<TResponse>
     {
        TResponse Get();
     }

 

I'm sharing these classes in one code snippet, but Commands and Queries will be lived in different assemblies although the above classes are bases and could be in an infrastructural assembly as well. Let's create a query sample. For example for querying a user detail, firstly I should create the related QueryView:

 


    public class UserDetailQueryView 
    {
        public int Id { get; set; }
        public string Username { get; set; }
    }

 

And then it's Query class turn. Note that the query class is just like Request in Request/Response pattern.

 

    public class UserDetailQuery : IQuery<UserDetailQueryView>
    {
        public long UserId { get; private set; }

        public UserDetailQuery(long userId)
        {
            UserId = userId;
        }
     }

 

And then create the handler of the above Query:

 

  
   internal class UserDetailQueryHandler : IQueryHandler<UserDetailQuery, 
   UserDetailQueryView>
    {
        private readonly UserDetailQuery _userDetailQuery;
     
        public UserDetailQueryHandler(UserDetailQuery userDetailQuery)
        {
            _userDetailQuery = userDetailQuery;
        }

        public UserDetailQueryView Get()
        {
            var user = MyDdContext.Users.GetById(_userDetailQuery.UserId);
            return new UserDetailQueryView { Username = user.Username, Id = user.Id };       
        }
    }

 

As you know, it's not a good idea to directly call EF DbContext to fetch data, it's just a sample code I'm sharing over here. And finally let's aggregate the queries in one Factory class  like this:

 

    public static class UserQueryFactory
    {
        public static IQueryHandler<UserDetailQuery, UserDetailQueryView> 
        Build(UserDetailQuery query)
        {
            return new UserDetailQueryHandler(query);
        }
     }

 

Now add a Razor page just like it's depicted below:

 

 

Now you can call the UserQueryFactory class in the razor page that we have created:

 


    public class DetailModel : PageModel
    {
        public int UserId { get; set; }

        public UserDetailQueryView UserDetailQueryView { get; set; }

        public IActionResult OnGet()
        {
            var query = new UserDetailQuery(UserId);
            var queryHandler = UserQueryFactory.Build(query);
            UserDetailQueryView = queryHandler.Get();

            if (UserDetailQueryView == null)
            {
                return NotFound();
            }

            return Page();
        }
     }

 

Now if you are interested to know how I'm using Commands, stay with me to create another command sample. A command is something the changes the state of an object. Such an example, ChangePassword is a command. Let's create it.

 


    public class ChangePasswordCommand : ICommand<CommandResult>
    {
        public string Username { get; set; }

        public string OldPassword { get; set; }

        public string NewPassword { get; set; }

        public string ConfirmPassword { get; set; }
     }

 

And again we should create a handler for the above command:

 

   internal class UserCommandHandler : ICommandHandler<ChangePasswordCommand, 
   CommandResult>
    {
        public CommandResult Execute()
        {
            var commandResult = new CommandResult();

            try
            {
                //fetch data from database and change the password
                
            }
            catch (Exception exception)
            {
                commandResult.Faild = true;
            }

            return commandResult;
        }
     }

 

And finally, just like query, let's create a factory for having all of the handlers in one place:

 

    public static class UserCommandFactory
    {
        public static ICommandHandler<ChangePasswordCommand, CommandResult> 
        Build(ChangePasswordCommand command)
        {
            return new UserCommandHandler();
        }
     }

 

Create another razor page for ChangePassword and in the class create with the same name, add the following command for changing the password:

 

    public class ChangePasswordModel : PageModel
    {
        [BindProperty]
        public string Username { get; set; }

        [BindProperty]
        public string OldPassword { get; set; }

        [BindProperty]
        public string NewPassword { get; set; }

        [BindProperty]
        public string ConfirmPassword { get; set; }

        public IActionResult OnPost()
        {
            if (!ModelState.IsValid)
            {
                return Page();
            }

            var changePasswordCommand = new ChangePasswordCommand
            {
                ConfirmPassword = ConfirmPassword,
                NewPassword = NewPassword,
                OldPassword = OldPassword,
                Username = Username
            };

            var commandHandler = 
            UserCommandFactory.Build(changePasswordCommand);
            var commandResult = commandHandler.Execute();

            if(commandResult.Faild)
            {
                //redirect to error page or return the message
            }

            return RedirectToPage("./Index");
        }
     }

 

Voila!



Simple command handler in .net

 

I want to introduce a simple command handler pattern in order to separate commands and queries of your applications if it’s needed. Sometimes especially in large-scale applications, you need to have two layers for reading and write separated and assign two teams to work on them.

You can use the pattern in this post based on the complexity and needs of your application. I recommend that don’t call this CQRS pattern as it’s something completely different and more complex.

 

Get started and Create an interface with no any member:

public interface ICommand

    {

    }

You will see later in this blog post that ICommand is just a flag to determine the commands for the handler. Every command which is trying to make a change in application’s state should return a result. so create another interface named ICommandResult

public interface ICommandResult

    {

        string Message { get; }

        bool Success { get; }

    }

implement the above interface as CommandResult and derive the FailureResult and SuccessResult classes from:

internal abstract class CommandResult : ICommandResult

    {

        public string Message { get; protected set; }

        public bool Success { get; protected set; }

    }



internal class FailureResult : CommandResult

    {

        public FailureResult(string message)

        {

            Success = false;

            Message = message;

        }

    }



    internal class SuccessResult : CommandResult

    {

        public SuccessResult(string message)

        {

            Success = true;

            Message = message;

        }

    }

Now create an interface for handling the validations in CommandBus class:

internal interface IValidationHandler<in TCommand> where TCommand : ICommand

    {

        IEnumerable<ValidationResult> Validate(TCommand command);

    }

 And create a class for validations:

public class ValidationResult

    {

        /// <summary>

        /// Initializes a new instance of the <see cref="ValidationResult"/> class.

        /// </summary>

        public ValidationResult()

        {

        }



        /// <summary>

        /// Initializes a new instance of the <see cref="ValidationResult"/> class.

        /// </summary>

        /// <param name="memeberName">Name of the memeber.</param>

        /// <param name="message">The message.</param>

        public ValidationResult(string memeberName, string message)

        {

            MemberName = memeberName;

            Message = message;

        }



        /// <summary>

        /// Initializes a new instance of the <see cref="ValidationResult"/> class.

        /// </summary>

        /// <param name="message">The message.</param>

        public ValidationResult(string message)

        {

            Message = message;

        }



        /// <summary>

        /// Gets or sets the name of the member.

        /// </summary>

        /// <value>

        /// The name of the member.  May be null for general validation issues.

        /// </value>

        public string MemberName { get; set; }



        /// <summary>

        /// Gets or sets the message.

        /// </summary>

        /// <value>

        /// The message.

        /// </value>

        public string Message { get; set; }

    }

And now create the most used interface in this pattern. ICommandBus will be called as bus handler in every command:

public interface ICommandBus

    {

        ICommandResult Send<TCommand>(TCommand command) where TCommand : ICommand;

        IEnumerable<ValidationResult> Validate<TCommand>(TCommand command) where TCommand : ICommand;

    }

To implementing this interface, create a class again with the following definition:

  internal class CommandBus : ICommandBus

    {

        public ICommandResult Send<TCommand>(TCommand command) where TCommand : ICommand

        {

            var handler = DependencyResolver.Current.GetService<ICommandHandler<TCommand>>();



            if (!((handler != null) && handler != null))

            {

                throw new CommandHandlerNotFoundException(typeof(TCommand));

            }

            return handler.Execute(command);

        }



        public IEnumerable<ValidationResult> Validate<TCommand>(TCommand command) where TCommand : ICommand

        {

            var handler = DependencyResolver.Current.GetService<IValidationHandler<TCommand>>();

         

            if (!((handler != null) && handler != null))

            {

                throw new ValidationHandlerNotFoundException(typeof(TCommand));

            }

            return handler.Validate(command);

        }

    }

The above class will handle every command received from the bus. And now for executing the handler or so-called for implementing the business, you need an interface:

internal interface ICommandHandler<in TCommand> where TCommand : ICommand

    {

        ICommandResult Execute(TCommand command);

    }

And finally as I’m personally interested in to have my own exception handler, so I create a customized handler:

public class CommandHandlerNotFoundException : Exception

    {

        public CommandHandlerNotFoundException(Type type)

            : base(string.Format("Command handler not found for command type: {0}", type))

        {

        }

    }



    internal class ValidationHandlerNotFoundException : Exception

    {

        public ValidationHandlerNotFoundException(Type type)

            : base(string.Format("Validation handler not found for command type: {0}", type))

        {

        }

    }

Finished! Now let’s use the above codes in a real work application. We are going to handle the products of an e-commerce application as its business is easier to comprehend for everybody:

    public interface IProductCommand : ICommand

    {

        string Name { get; set; }



        string OriginalName { get; set; }



        string Description { get; set; }



        decimal Price { get; set; }

     

    }

  

    public class ProductCommand : IProductCommand

    {

        public string Name { get; set; }



        public string OriginalName { get; set; }



        public string Description { get; set; }



        public decimal Price { get; set; }     

    }



    public class CreateProductCommand : ProductCommand

    {

    }



    public class EditProductCommand : ProductCommand

    {

        public Guid ProductId { get; set; }



        public DateTime CreationDate { get; set; }



        public DateTime LastUpdateDate { get; set; }

    }



public class DeleteProductCommand : ICommand

    {

        public Guid[] ProductIds { get; set; }

    }

You can see that I created an interface derived from ICommand named IProductCommand and finally created the target classes. And at the end we should create the Product handler class:

internal partial class ProductCommandHandler :

        ICommandHandler<CreateProductCommand>,

        ICommandHandler<EditProductCommand>,   

        ICommandHandler<DeleteProductCommand>       

    {

        private readonly IProductRepository _productRepository;

        private readonly IMembershipRepository _membershipRepository;     

        private readonly IUnitOfWork _unitOfWork;

        private readonly ICacheManager _cacheManager;

        private readonly ILogger _logger;



        public ProductCommandHandler(

            IProductRepository productRepository,        

            IUnitOfWork unitOfWork,

            ILogger logger,

            ICacheManager cacheManager)

        {

            _productRepository = productRepository;          

            _unitOfWork = unitOfWork;

            _logger = logger;

            _cacheManager = cacheManager;        

        }

       

        public ICommandResult Execute(CreateProductCommand command)

        {

            try

            {

                if (command == null)

                {

                    throw new ArgumentNullException();

                }



                var product = new Product();

                AddProductAppurtenance(command, product);

                _productRepository.Add(product);

                _unitOfWork.Commit();

                return new SuccessResult(ProductCommandMessage.ProductCreatedSuccessfully);

            }

            catch (Exception exception)

            {

                _logger.Error(exception.Message);

                return new FailureResult(ProductCommandMessage.ProductCreationFailed);

            }

        }



        public ICommandResult Execute(EditProductCommand command)

        {

            try

            {

                if (command == null)

                {

                    throw new ArgumentNullException();

                }



                var product = _productRepository.GetProductDetailById(command.ProductId);

                ClearProductAppurtenance(product);

                AddProductAppurtenance(command, product);

                _productRepository.Edit(product);

                _unitOfWork.Commit();



                return new SuccessResult(ProductCommandMessage.ProductEditedSuccessfully);

            }

            catch (Exception exception)

            {

                _logger.Error(exception.Message);

                return new FailureResult(ProductCommandMessage.ProductEditionFailed);

            }

        }



        public ICommandResult Execute(DeleteProductCommand command)

        {

            if (command.ProductIds == null)

            {

                throw new ArgumentNullException();

            }



            var exceptions = new List<Exception>();

            foreach (var productId in command.ProductIds)

            {

                try

                {

                    var product = DeleteProduct(productId);

                    _productRepository.Edit(product);

                }

                catch (Exception exception)

                {

                    exceptions.Add(exception);

                    return new FailureResult(ProductCommandMessage.ProductDeletionFailed);

                }

            }



            if (exceptions.Any())

            {

                throw new AggregateException(exceptions);

            }



            _unitOfWork.Commit();

            return new SuccessResult(ProductCommandMessage.ProductsDeletedSuccessufully);

        }  

 

We used all of the classes introduced in infrastructure.

Note 1: so you need to have an IOC container tool, to the best of my Knowledge, AsClosedTypesOf in Autofac resolves the ICommandHandler. This a piece of code I wrote for IOC handler:

  public class CommandModule : Module

    {

        protected override void Load(ContainerBuilder builder)

        {

            builder.RegisterModule<RepositoryModule>();

            builder.RegisterType<CommandBus>().As<ICommandBus>().InstancePerRequest();

            builder.RegisterAssemblyTypes(ThisAssembly).AsClosedTypesOf(typeof(ICommandHandler<>)).InstancePerRequest();

        }

    }

Note 2: a penny for your thoughts! how to use ICommandBus!? See the below piece of code as an example:

[HttpPost]

        public JsonResult DeleteProduct(DeleteProductCommand command)

        {

            var result = _commandBus.Send(command);

            return JsonMessage(result);

        }

have fun.



Disadvantages of n-layered architectures

Most of the people use n-layered architectures in their application development. There are lots of advantage for n-layered architecture but I want to talk about the disadvantages. actually, it's not a good idea to design a complex architecture for every problem, you don't need to apply n-layered architecture in every case because it's mostly about making complex things simple whilst a complex architecture can make a system more and more hard to understand rather than making performance problems. Based on this presentation, making software via n-layered application could be cost-effective and dangerous for performance. Suppose an architecture like the picture below:

n-layered

 

When you make a request from your browser your request goes throw several layers and assemblies to persist your request in database and then comes back the same way to make a change (you can simply assume the scenario like the picture!). Let's take an example about that, imagine that I'm gonna to persist the sent message(Contact) by the user in "ContactUs" of the n-layered architecture website (the same example I showed in StackOverflow).

This is my action to create the Contact:

 

[HttpPost]
public ActionResult Create(ContactViewModel contactViewModel)
{
    var request = new CreateContactRequest(contactViewModel);
    _contactService.CreateContact(request);
    return View();
}

 

and about the service implementation, I've done like this:

 

public CreateContactResponse CreateContact(CreateContactRequest request)
{
    var response = new CreateContactResponse();
    var contact = request.ContactViewModel.ConvertToContactModel();
    try
    {
        _contactRepository.Add(contact);
        _unitOfWork.Commit();
        response.Success = true;
        response.MessageType = MessageType.Success;
        response.Message = ServiceMessages.GeneralServiceSuccessMessageOnCreation;
        _logger.Log(response.Message);
    }
    catch (Exception exception)
    {
        response.Success = false;
        response.MessageType = MessageType.UnSuccess;
        response.Message = ServiceMessages.GeneralServiceErrorMessageOnCreation;
        _logger.Error(exception.Message);
    }
    return response;
}

  

And  finally in the repository layer, I have this generic Add method:

 

public void Add(T entity)
{
    SessionFactory.GetCurrentSession().Save(entity);
}

 

As you can see there are lots scenario in this example such as converting ViewModel to Model, using request and response pattern in Service, injecting the interfaces,  adding to the repository, committing by UnitOfWork and blah blah. But you I can also do all of above with just a simple action method:

 

[HttpPost]
public ActionResult Create(Contact contact)
{
    SessionFactory.GetCurrentSession().Save(contact);
    return View();
}

 

You know the above implementation on an action is not the best solution when your application is complex and large scale, but if it is not trying to use something like that as it's easy to develop and defiantly high performance.

Optimizing n-layered architectures is not an easy task, But it is easy to change the content of any layer without making corresponding changes in other layers. It is more readable, maintainable, extensible, flexible, testable and is suitable for parallel development especially in team working but you know it has its own disadvantages.

If you have enough factors to break your application into layers, for example, if you want to let other applications to access to your application via a service, separate your concerns; so apply to layered architecture but keep in mind that:

 

  1. This architecture leads to the reduction of network traffic, faster network communications, greater reliability, and greater overall performance.
  2. As layers usually live in separate assemblies so This results in high communications overhead.
  3. More layer cause more network and network bandwidth, the process involved. 



What's the DDD-lite?

Based on Vaughn Vernon 's definition, "DDD-Lite is a means of picking and choosing a subset of the DDD tactical patterns, but without giving full attention to discovering, capturing, and enhancing the Ubiquitous Language." most of the DDD-like approaches are not really DDD! If you don’t have bounded contexts so Ubiquitous language(UL) doesn't mean anything and if you have no UL, you won't have business rules.

In DDD, you should concentrate on a domain model and establish a ubiquitous language and use the patterns of DDD. But most of the cases your application is not complex and big enough to apply the whole DDD approach. but for more and different reasons you are going to use DDD patterns. For example when your application doesn't have any complex and different scenarios to separate them as bounded contexts or SubDomains - and you just embrace technical tools, concepts and patterns of DDD like simple entities, services, repositories, aggregates. In these cases, you can use patterns of DDD within your code and call it "DDD-lite".

I started a project about 10 days ago, it's so interesting that I just read about DDD-lite yesterday; but when I designed the architecture of the project, as I'm really interested in DDD I assigned entities as Aggregate and used the repository and layerSupertype patterns, Repository and Service layers. But I don't have any bounded context, value object, subdomain, UL, Domain Service or context map in this project. I've approximately finished the project, I'm gonna to describe the architecture of the project in a few days after hosting in this tag of my blog with "Statos" title.

As usual, it's my pleasure you to correct my mistakes, thanks



Domain driven design VS model driven architecture

Domain Driven design(DDDesign) is not the same Model Driven Architecture(MDA). Although The root of both DDDesign and MDA is the same and it is Model Driven Engineering and also both of them aim to solve the problem of converting a 'pure' problem domain model into a full software system. But there are some differences.

Domain Driven Design concentrates on Modeling and solving the Domain problem by Capturing the model from the Ubiquitous language. it is about modeling a domain of knowledge with a high level of abstraction and its focuses are on domain logic and tries to keep the design as much close to the real world. In DDDesign you create the model with the Ubiquitous language so you should understand the business without any technical issues. In another side, model forms the ubiquitous language of DDDesign which explains the domain in a simple form and it's kinda a backbone of DDDesign.

But Model-driven architecture is an approach to building the model of the system. As I mentioned MDA is a kind of domain engineering too. A model is just some taken classes, methods and ... from the problem domain. MDA provides you to use multiple standards such as UML. 

 

but you know it doesn't stop there, I don't know more than these two paragraphs about differences of DDD and MDA! please let me know more about these two architectures and differences by comments, thanks...



About Me

Ehsan Ghanbari

Hi! my name is Ehsan. I'm a developer, passionate technologist, and fan of clean code. I'm interested in enterprise and large-scale applications architecture and design patterns and I'm spending a lot of my time on architecture subject. Since 2008, I've been as a developer for companies and organizations and I've been focusing on Microsoft ecosystem all the time. During the&nb Read More

Post Tags
Pending Blog Posts
Strategic design
Factory Pattern
time out pattern in ajax
Selectors in Jquery
Peridic pattern
How to query over Icollection<> of a type with linq
How to use PagedList In asp.net MVC
Domain driven design VS model driven architecture
What's the DDD-lite?
Redis as a cache server