Clean Up Your Client to Business Logic Relationship With a Result Pattern (C#)

If you’ve been developing well structured and scalable code bases, you probably focus a whole lot on your “Separation of Concerns”. Maybe you implement a design pattern or code architectures like SOLID, Clean, or Onion to enforce some stricter rules around those separations.

In the .NET world, we use a lot of Inversion of Control and Dependency Injection. Especially in ASP.NET Core. However, I find that a lot of implementations are still missing one big separation – error handling.

The most common case I see in a decently structured application is:

  • Controller injects a service
  • Service runs business logic
  • On error, service throws exception
  • Controller exposes that an error happened via catching exception

One problem I have with this is that the Controller is now handling some business logic by managing the error. So what is my proposal? Handle your business logic errors / validation and expose the result of that logic, whether successful or with errors, to the controller that then determines the proper HTTP Response Code and message to return based on the type of result.

This is often just called the Result Pattern but I think it goes beyond this concept when wrapping it up into something like CLEAN or Onion. So, I often refer to it as the Service Result Pattern. I typically employ this pattern in all of my applications – back end and front end alike.

Here is what it looks like in C#. We want to create a Result object that our business logic will return to our Controller, ViewModel, View, etc. Samples here will be referring to an ASP.NET Core 2.1 RESTful API implementation, but the pattern can be applied everywhere.

So we need:
– Result classes
– A controller that returns IActionResult
– A business logic class that returns a Result
– Validation and error handling logic

The Result Model

I’ve created a NuGet package for these Result models if you want to use those, but these are the essentials duplicated here if you want to do it yourself. The package can be found here:

NuGet: https://www.nuget.org/packages/ServiceResult/
GitHub: https://github.com/SuavePirate/ServiceResult

First we want an abstract Result class that contains the data, errors, and the type. Then we can create child types that can make the typing of our results stronger.

Result.cs

public abstract class Result<T>
{
    public abstract ResultType ResultType { get; }
    public abstract List<string> Errors { get; }
    public abstract T Data { get; }
}

ResultType.cs

public enum ResultType
{
    Ok,
    Invalid,
    Unauthorized,
    PartialOk,
    NotFound,
    PermissionDenied,
    Unexpected
}

The idea is that for each one of these result types, we should have a strongly typed implementation. Here are a few examples of the most commonly used ones.

InvalidResult.cs

public class InvalidResult<T> : Result<T>
{
    private string _error;
    public InvalidResult(string error)
    {
        _error = error;
    }
    public override ResultType ResultType => ResultType.Invalid;

    public override List<string> Errors => new List<string> { _error ?? "The input was invalid." };

    public override T Data => default(T);
}

UnexpectedResult.cs

public class UnexpectedResult<T> : Result<T>
{
    public override ResultType ResultType => ResultType.Unexpected;

    public override List<string> Errors => new List<string> { "There was an unexpected problem" };

    public override T Data => default(T);
}

SuccessResult.cs

public class SuccessResult<T> : Result<T>
{
    private readonly T _data;
    public SuccessResult(T data)
    {
        _data = data;
    }
    public override ResultType ResultType => ResultType.Ok;

    public override List<string> Errors => new List<string>();

    public override T Data => _data;
}

Notice how the only one that implements Data as anything other than default(T) is the SuccessResult. This guarantees us our data is consistent based on the result type and we can instead use different error types to map the proper error messages, ResultType, etc.

Using the Result in Business Logic

Let’s take a look at a sample of how we can use these models in our business logic to house all our success and error logic.

MyService

public class MyService : IMyService
{
    private readonly IMyRepository _repository;
    private readonly IPermissionService _permissions;

    public MyService (IMyRepository repository, IPermissionService permissions)
    {
        _repository = repository;
        _permissions = permissions;
    }

    public async Task<Result<MyDTO>> GetSomethingAsync(string id)
    {
        try
        {
            if(string.IsNullOrEmpty(id))
                return new InvalidResult<MyDTO>("Invalid ID");

            var hasPermission = await _permissions.HasPermissionsToDoSomethingAsync();
            if(!hasPermission)
                return new AccessDeniedResult<MyDTO>();

            var myData = await _repository.FindAsync(id);
            if(myData == null)
                return new NotFoundResult<MyDTO>();

            return new SuccessResult<MyDTO>(new MyDTO(myData));
        }
        catch(Exception ex)
        {
            Console.WriteLine(ex);
            return new UnexpectedResult<MyDTO>();
        }
    }
}

This shows how we can use our different Result classes to step through our business logic in a very flat easy to follow and read way while still managing errors consistently.

Build an IActionResult from a Result

Once we have a Result returned, we want to give our controller the ability to map the type and data to the proper HTTP response. Doing this ensures that our Controller is only responsible for HTTP related logic, and not for business logic.

I’ve done this in the past with either a BaseController or with an extension method. If you want a simple extension method, check out my other NuGet package for it:

NuGet: https://www.nuget.org/packages/ServiceResult.ApiExtensions/
GitHub: https://github.com/SuavePirate/ServiceResult

Here’s what that method would look like:

ControllerExtensions

public static ActionResult FromResult<T>(this ControllerBase controller, Result<T> result)
{
    switch (result.ResultType)
    {
        case ResultType.Ok:
            return controller.Ok(result.Data);
        case ResultType.NotFound:
            return controller.NotFound(result.Errors);
        case ResultType.Invalid:
            return controller.BadRequest(result.Errors);
        case ResultType.Unexpected:
            return controller.BadRequest(result.Errors);
        case ResultType.Unauthorized:
            return controller.Unauthorized();
        default:
            throw new Exception("An unhandled result has occurred as a result of a service call.");
    }
}

With this, our Controller methods can be made extremely clean. Here’s an example:

MyController.cs

public class MyController : Controller
{
    private readonly IMyService _service;
    public MyController(IMyService service)
    {
        _service = service;
    }

    [HttpGet]
    public async Task<IActionResult> GetSomethingAsync(string id)
    {
        var result = await _service.GetSomethingAsync(id);
        return this.FromResult(result);
    }
}

Assuming our _service.GetSomethingAsync() returns a Task we can keep all our endpoints clean and only responsible for being a gateway to our application logic! So clean ūüėÄ

Conclusion

All together, we are able to ensure our error logic lives within our application/business logic and that our Controllers are able to worry just about the HTTP side of things. We do a better job at separating our concerns, we keep our business logic flat and easy to follow, and we provide our consumers of our application easy to follow data and errors by ensuring we return the proper HTTP responses and structures.


If you like what you see, don’t forget to follow me on twitter @Suave_Pirate, check out my GitHub, and subscribe to my blog to learn more mobile developer tips and tricks!

Interested in sponsoring developer content? Message @Suave_Pirate on twitter for details.

Advertisements

Markdig Extension – Bad Header Handler

First off, if you haven’t seen Markdig yet, you’re missing out! It has to be the most extensible Markdown processor I’ve ever seen, and it is still incredibly fast. It’s slim enough to confidently use on small .NET Clients like Xamarin, and supports custom output as well (not just HTML).

Because of it’s flexibility and componentization, we are able to customize it without sacrificing performance using their “Extension” framework. The extension we are talking about here is one that ideally would never exist, but solves the problem of malformed Markdown headers. How often do you see wrong headers with the missing space after the “#” in places like Github and WordPress?

Where

#My Header

Should be

# My Header

Well if you’re using Markdig and run into this issue, simply slap this extension into your processing pipeline and worry no more! It even works with a mix of good and bad headers.

Install

You can find it on NuGet or Clone it yourself from Github:

Usage

Add it to your pipeline that you use to parse:

var pipelineBuilder = new MarkdownPipelineBuilder();
pipelineBuilder = MarkdownExtensions.Use<BadHeadersExtension>(pipelineBuilder);
var pipeline = pipelineBuilder.Build();
var html = Markdown.ToHtml(BAD_HEADER_MARKDOWN, _pipeline);

Check out the unit tests in the source code to view a working example.

Source

The gist is a HeadingBlockParser and the Extension itself.

BadHeadingBlockParser.cs

<br />    /// <summary>
    /// Bad heading block parser. Does the same thing as the header parser, but doesn't require a space.
    /// Using a private class to ensure all markdown logic is contained within this service.
    /// </summary>
    public class BadHeadingBlockParser : HeadingBlockParser
    {
        /// <summary>
        /// The head char.
        /// </summary>
        private readonly char _headChar;

        /// <summary>
        /// Initializes a new instance of the <see cref="T:Markdig.BadHeaders.BadHeadingBlockParser"/> class.
        /// </summary>
        /// <param name="headChar">Head char.</param>
        public BadHeadingBlockParser(char headChar)
        {
            _headChar = headChar;
        }

        /// <summary>
        /// Overrides the TryOpen for the heading block parser to ignore the need for spaces
        /// </summary>
        /// <returns>The open.</returns>
        /// <param name="processor">Processor.</param>
        public override BlockState TryOpen(BlockProcessor processor)
        {
            // If we are in a CodeIndent, early exit
            if (processor.IsCodeIndent)
            {
                return BlockState.None;
            }

            // 4.2 ATX headings
            // An ATX heading consists of a string of characters, parsed as inline content, 
            // between an opening sequence of 1‚Äď6 unescaped # characters and an optional 
            // closing sequence of any number of unescaped # characters. The opening sequence 
            // of # characters must be followed by a space or by the end of line. The optional
            // closing sequence of #s must be preceded by a space and may be followed by spaces
            // only. The opening # character may be indented 0-3 spaces. The raw contents of 
            // the heading are stripped of leading and trailing spaces before being parsed as 
            // inline content. The heading level is equal to the number of # characters in the 
            // opening sequence.

            // We are not doing this ^^ we don't have the spaces... so we need to handle that adjusted logic here
            var column = processor.Column;
            var line = processor.Line;
            var sourcePosition = line.Start;
            var c = line.CurrentChar;
            var matchingChar = c;

            int leadingCount = 0;

            // get how many of the headChar we have and limit to 6 (h6 is the last handled header)
            while (c == _headChar && leadingCount <= 6)
            {
                if (c != matchingChar)
                {
                    break;
                }
                c = line.NextChar();
                leadingCount++;
            }

            // A space is NOT required after leading #
            if (leadingCount > 0 && leadingCount <= 6)
            {
                // Move to the content
                var headingBlock = new HeadingBlock(this)
                {
                    HeaderChar = matchingChar,
                    Level = leadingCount,
                    Column = column,
                    Span = { Start = sourcePosition }
                };
                processor.NewBlocks.Push(headingBlock);
                processor.GoToColumn(column + leadingCount); // no +1 - skip the space

                // Gives a chance to parse attributes
                if (TryParseAttributes != null)
                {
                    TryParseAttributes(processor, ref processor.Line, headingBlock);
                }

                // The optional closing sequence of #s must not be preceded by a space and may be followed by spaces only.
                int endState = 0;
                int countClosingTags = 0;
                for (int i = processor.Line.End; i >= processor.Line.Start; i--)  // Go up to Start in order to match the no space after the first ###
                {
                    c = processor.Line.Text[i];
                    if (endState == 0)
                    {
                        if (c.IsSpaceOrTab())
                        {
                            continue;
                        }
                        endState = 1;
                    }
                    if (endState == 1)
                    {
                        if (c == matchingChar)
                        {
                            countClosingTags++;
                            continue;
                        }

                        if (countClosingTags > 0)
                        {
                            if (c.IsSpaceOrTab())
                            {
                                processor.Line.End = i - 1;
                            }
                            break;
                        }
                        else
                        {
                            break;
                        }
                    }
                }

                // Setup the source end position of this element
                headingBlock.Span.End = processor.Line.End;

                // We expect a single line, so don't continue
                return BlockState.Break;
            }

            // Else we don't have an header
            return BlockState.None;
        }
    }

 
Then we use the Parser in the Extension:

BadHeadersExtension.cs

<br />    /// <summary>
    /// Markdig markdown extension for handling bad markdown for titles
    /// </summary>
    public class BadHeadersExtension : IMarkdownExtension
    {
        /// <summary>
        /// Sets up the extension to use the badheading block parser
        /// </summary>
        /// <returns>The setup.</returns>
        /// <param name="pipeline">Pipeline.</param>
        public void Setup(MarkdownPipelineBuilder pipeline)
        {
            if (!pipeline.BlockParsers.Contains<BadHeadingBlockParser>())
            {
                // Insert the parser before any other parsers and use '#' as the character identifier
                pipeline.BlockParsers.Insert(0, new BadHeadingBlockParser('#'));
            }
        }

        /// <summary>
        /// Not needed
        /// </summary>
        /// <returns>The setup.</returns>
        /// <param name="pipeline">Pipeline.</param>
        /// <param name="renderer">Renderer.</param>
        public void Setup(MarkdownPipeline pipeline, IMarkdownRenderer renderer)
        {
            // not needed
        }
    }

If you like what you see, don’t forget to follow me on twitter @Suave_Pirate, check out my GitHub, and subscribe to my blog to learn more mobile developer tips and tricks!

Interested in sponsoring developer content? Message @Suave_Pirate on twitter for details.

.NET Flux Toolkit Nuget Announcement

Last week I mentioned that I was going to be publishing some of my GitHub library projects on Nuget to make them easier to integrate into your projects – Here’s the newest library for using the Flux in your .NET applications such as Xamarin, UWP, WPF, WinForms, and even ASP.NET.

Nuget: https://www.nuget.org/packages/FluxToolkit/
GitHub: https://github.com/SuavePirate/FluxToolkit/

Here’s how to get started!

FluxToolkit

A super simple library to enable the implementation of Flux in .NET Applications such as Xamarin, UWP, WPF, and more. It contains some base level Flux components to help you get started with your implementation faster.

What is Flux?

Flux is a design pattern created by Facebook with the purpose of creating robust data-driven UI components and handles the flow of data between components and outward to services.

Components

Flux consists of 4 major components – Stores, Actions, Components, and the Dispatcher

Stores

Stores are responsible for containing and managing data for a single domain or data type. Stores listen to the dispatcher for certain events and use the data from the dispatcher to update their data, handle errors, and then pass that update down to the components that are subscribed to the store.

Actions

Actions are responsible for piping events through the dispatcher. Actions are invoked from Components or from background processes. They can also handle some small business logic such as data mapping or talking to external services.

Components

Components are the UI and UI logic layers. They are responsible for displaying views to the users and for handling user events. They invoke Actions and subsribe to Stores to handle updates to the data.

Dispatcher

A single dispatcher is responsible for the Pub/Sub mechanism of events invoked from Actions. Stores subscribe to events by name through the Dispatcher.

How does it work with MVVM and data binding?

ViewModels can be considered part of the Component layer but are separated from the actual UI/Views. This means that the ViewModels are responsible for invoking Actions, and subscribing to Stores. The Views themselves are only responsible for showing the UI and communicating to the ViewModel.

Getting Started

Install

The FluxToolkit is available on Nuget: https://www.nuget.org/packages/FluxToolkit It has no external dependencies and should work with any .NET Standard library or project including Xamarin, Xamarin.Forms, UWP, WPF, and even WinForms. It has not been used for web application development, but it is compatible with ASP.NET projects.

Install the nuget package with the nuget package manager or via the Package Manager command line:

Install-Package FluxToolkit

Create your Stores

Use the¬†StoreBase¬†class from the FluxToolkit to implement your unique stores for your different data types. It contains a generic¬†Data¬†field based on the¬†TData¬†type you pass into the definition. Now you don’t have to worry about communicating to the dispatcher for pub/sub – simply call the base methods for¬†Subsribe¬†and¬†Unsubscribe.

Ensure that you are not using multiple instances of your Stores, but rather should be using either a Singleton or Inversion of Control with Dependency Injection to pass the implementation of your Store to the Components that require it through the constructor. Constantly creating new Stores can cause memory leaks due to the event subscriptions.

Here’s an example store implementation:

    /// <summary>
    /// Event store for holding and managing todo items
    /// </summary>
    public class TodoStore : StoreBase<ObservableCollection<Todo>>
    {
        /// <summary>
        /// Creates a new store and handles subscriptions to the dispatcher
        /// </summary>
        public TodoStore()
        {
            Subscribe<string>(TodoActionTypes.ADD_TODO);
            Subscribe(TodoActionTypes.DELETE_COMPLETED_TODOS);
            Subscribe<string>(TodoActionTypes.DELETE_TODO);
            Subscribe<Todo>(TodoActionTypes.EDIT_TODO);
            Subscribe(TodoActionTypes.TOGGLE_ALL_TODOS);
            Subscribe<string>(TodoActionTypes.TOGGLE_TODO);

            Data = new ObservableCollection<Todo>();
        }

        /// <summary>
        /// Processes an event from the dispatcher before emitting it.
        /// </summary>
        /// <typeparam name="TData"></typeparam>
        /// <param name="eventType"></param>
        /// <param name="data"></param>
        protected override void ReceiveEvent<TData>(string eventType, TData data)
        {
            try
            {
                Error = null;
                switch (eventType)
                {
                    case TodoActionTypes.ADD_TODO:
                        Data.Add(new Todo
                        {
                            Id = Guid.NewGuid().ToString(),
                            Text = data as string,
                            IsComplete = false
                        });
                        break;
                    case TodoActionTypes.DELETE_COMPLETED_TODOS:
                        var itemsToRemove = Data.Where(t => t.IsComplete);
                        foreach(var item in itemsToRemove.ToList())
                        {
                            Data.Remove(item);
                        }
                        break;
                    case TodoActionTypes.DELETE_TODO:
                        var itemToRemove = Data.FirstOrDefault(t => t.Id == data as string);
                        if (itemToRemove != null)
                            Data.Remove(itemToRemove);
                        break;
                    case TodoActionTypes.EDIT_TODO:
                        var itemToEdit = Data.FirstOrDefault(t => t.Id == (data as Todo).Id);
                        if (itemToEdit != null)
                            itemToEdit.Text = (data as Todo).Text;
                        break;
                    case TodoActionTypes.TOGGLE_ALL_TODOS:
                        var areAllComplete = !Data.Any(t => !t.IsComplete);
                        foreach(var todo in Data)
                        {
                            todo.IsComplete = !areAllComplete;
                        }
                        break;
                    case TodoActionTypes.TOGGLE_TODO:
                        var itemToToggle = Data.First(t => t.Id == (data as string));
                        if (itemToToggle != null)
                            itemToToggle.IsComplete = !itemToToggle.IsComplete;
                        break;

                }
            }
            catch (Exception ex)
            {
                // if something goes wrong, set the error before emitting
                Error = ex.Message;
            }
           
            base.ReceiveEvent(eventType, data);
        }
    }

Create your Actions

Create an Actions class for each of your main data types. These actions will call to the Dispatcher to fire events and will also need to implement IActions in order to properly handle the pub/sub mechanism.

    /// <summary>
    /// Actions to be taken against Todo items
    /// </summary>
    public class TodoActions : IActions
    {
        public void AddTodo(string text)
        {
            Dispatcher.Send<IActions, string>(this, TodoActionTypes.ADD_TODO, text);
        }

        public void DeleteCompletedTodos()
        {
            Dispatcher.Send<IActions>(this, TodoActionTypes.DELETE_COMPLETED_TODOS);
        }

        public void DeleteTodo(string id)
        {
            Dispatcher.Send<IActions, string>(this, TodoActionTypes.DELETE_TODO, id);
        }

        public void EditTodo(string id, string text)
        {
            Dispatcher.Send<IActions, Todo>(this, TodoActionTypes.EDIT_TODO, new Todo
            {
                Id = id,
                Text = text
            });
        }

        public void StartEditingTodo(string id)
        {
            Dispatcher.Send<IActions, string>(this, TodoActionTypes.START_EDITING_TODO, id);
        }

        public void StopEditingTodo()
        {
            Dispatcher.Send<IActions>(this, TodoActionTypes.STOP_EDITING_TODO);
        }

        public void ToggleAllTodos()
        {
            Dispatcher.Send<IActions>(this, TodoActionTypes.TOGGLE_ALL_TODOS);
        }

        public void ToggleTodo(string id)
        {
            Dispatcher.Send<IActions, string>(this, TodoActionTypes.TOGGLE_TODO, id);
        }
        
    }

Define your ActionTypes

For each of your data types, you’ll need to define some¬†ActionTypes¬†which translate to the¬†id¬†or¬†name¬†of the events your¬†Actions¬†are invoking through the¬†Dispatcher.

    /// <summary>
    /// Different types of actions that can be completed within the context of Todo items
    /// </summary>
    public class TodoActionTypes
    {
        public const string ADD_TODO = "add_todo";
        public const string DELETE_COMPLETED_TODOS = "delete_completed_todos";
        public const string DELETE_TODO = "delete_todo";
        public const string EDIT_TODO = "edit_todo";
        public const string START_EDITING_TODO = "start_editing_todo";
        public const string STOP_EDITING_TODO = "stop_editing_todo";
        public const string TOGGLE_ALL_TODOS = "toggle_all_todos";
        public const string TOGGLE_TODO = "toggle_todo";
        public const string UPDATE_DRAFT = "update_draft";
    }

Wire up your Components (with MVVM or without)

Have your components subscribe to the Stores that are appropriate for the data need, and invoke the Actions they need. This is a great place to place inject your Stores and Actions into the constructor of your Componentswhether it is through a ViewModel or an Activity, ViewController, or Xamarin.Forms.Page.

    public class TodoListPageViewModel : BasePageViewModel
    {
        private readonly TodoStore _todoStore;
        private readonly TodoActions _todoActions;
        private ObservableCollection<Todo> _items;
        private ICommand _createCommand;
        private ICommand _toggleCommand;
        private ICommand _toggleAllCommand;
        private ICommand _deleteCommand;
        private ICommand _deleteCompletedCommand;
        private ICommand _editCommand;
        private ICommand _populateCommand;

        public ICommand CreateCommand
        {
            get
            {
                return _createCommand ??
                    (_createCommand = new RelayCommand(async () =>
                    {
                        var result = await UserDialogs.Instance.PromptAsync(string.Empty, "New", "Done", "Cancel", "Todo...");
                        if (result.Ok)
                        {
                            _todoActions.AddTodo(result.Text);
                        }
                    }));
            }
        }

        public ICommand EditCommand
        {
            get
            {
                return _editCommand ??
                    (_editCommand = new RelayCommand<Todo>(async (t) =>
                    {
                        var result = await UserDialogs.Instance.PromptAsync(new PromptConfig()
                            .SetText(t.Text)
                            .SetTitle("Edit")
                            .SetOkText("Done")
                            .SetCancelText("Cancel")
                            .SetPlaceholder("Todo..."));
                        if (result.Ok)
                        {
                            _todoActions.EditTodo(t.Id, result.Text);
                        }
                    }));
            }
        }

        public ICommand ToggleCommand
        {
            get
            {
                return _toggleCommand ??
                    (_toggleCommand = new RelayCommand<Todo>((t) =>
                    {
                        _todoActions.ToggleTodo(t.Id);
                    }));
            }
        }

        public ICommand ToggleAllCommand
        {
            get
            {
                return _toggleAllCommand ??
                    (_toggleAllCommand = new RelayCommand(() =>
                    {
                        _todoActions.ToggleAllTodos();
                    }));
            }
        }

        public ICommand DeleteCommand
        {
            get
            {
                return _deleteCommand ??
                    (_deleteCommand = new RelayCommand<Todo>((t) =>
                    {
                        _todoActions.DeleteTodo(t.Id);
                    }));
            }
        }

        public ICommand DeleteCompletedCommand
        {
            get
            {
                return _deleteCompletedCommand ??
                    (_deleteCompletedCommand = new RelayCommand(() =>
                    {
                        _todoActions.DeleteCompletedTodos();
                    }));
            }
        }

        public ICommand PopulateCommand
        {
            get
            {
                return _populateCommand ??
                    (_populateCommand = new RelayCommand(() =>
                    {
                        for(var i = 1; i < 20; i++)
                        {
                            _todoActions.AddTodo($"New Item {i}");
                            Task.Delay(200);
                        }
                    }));
            }
        }

        public ObservableCollection<Todo> Items
        {
            get
            {
                return _todoStore.Data;
            }
        }

        public TodoListPageViewModel(TodoStore todoStore, TodoActions todoActions)
        {
            _todoStore = todoStore;
            _todoActions = todoActions;
            _todoStore.OnEmitted += TodoStore_OnEmitted;
        }

        /// <summary>
        /// Processes events from the todo store and updates any UI that isn't handled automatically
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        private void TodoStore_OnEmitted(object sender, StoreEventArgs e)
        {
            switch (e.EventType)
            {
                case TodoActionTypes.ADD_TODO:
                    if(_todoStore.Error == null)
                    {
                        UserDialogs.Instance.Toast("Item added");
                    }
                    break;
                case TodoActionTypes.DELETE_COMPLETED_TODOS:
                    if (_todoStore.Error == null)
                    {
                        UserDialogs.Instance.Toast("Items deleted");
                    }
                    break;
                case TodoActionTypes.DELETE_TODO:
                    if (_todoStore.Error == null)
                    {
                        UserDialogs.Instance.Toast("Item deleted");
                    }
                    break;
                case TodoActionTypes.TOGGLE_ALL_TODOS:
                    if (_todoStore.Error == null)
                    {
                        UserDialogs.Instance.Toast("Items toggled");
                    }
                    break;
                case TodoActionTypes.TOGGLE_TODO:
                    if (_todoStore.Error == null)
                    {
                        UserDialogs.Instance.Toast("Item toggled");
                    }
                    break;
            }
            if(_todoStore.Error != null)
            {
                UserDialogs.Instance.ShowError(_todoStore.Error);
            }
        }
    }

Contributing

Want to add additional examples or more tooling to help people develop their apps with Flux? Fork this repository and create a pull request!

Additional Resources

 

If you like what you see, don’t forget to follow me on twitter @Suave_Pirate, check out my GitHub, and subscribe to my blog to learn more mobile developer tips and tricks!

Interested in sponsoring developer content? Message @Suave_Pirate on twitter for details.

ASP.NET.Tips – Consuming Bearer Tokens as a Cookie

A while ago, I talked about creating a super basic OAuth Bearer and Refresh Token System in your ASP.NET web applications: Adding a Simple Refresh Token to OAuth Bearer Tokens

Now, almost two years later, we will expand on this by creating a Cookie provider that consumes your bearer tokens to make Authorization easier. One reason to consider doing this is if you are using SignalR or any other socket service with your OAuth tokens. You can add your Bearer token in your Authorization header of your requests to SignalR, however, doing this will force your client to use LongPolling rather than actually using WebSockets as it is intended.

So, let’s create our provider:

OAuthCookieProvider.cs

 public class OAuthCookieProvider : OAuthBearerAuthenticationProvider
    {
        public override Task RequestToken(OAuthRequestTokenContext context)
        {
            if (context == null) throw new ArgumentException("context");
            var tokenCookie = context.OwinContext.Request.Cookies["BearerToken"];
            if (!string.IsNullOrEmpty(tokenCookie))
            {
                context.Token = tokenCookie;
                return Task.FromResult<object>(null);
            }
            return base.RequestToken(context);
        }
    }

And now let’s get that registered with Owin:

Startup.cs

...
public void Configuration(IAppBuilder app)
{
    app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions
    {
        Provider = new OAuthCookieProvider()
    });
}
...

Now we can send requests with our HTTP cookie with the key of BearerToken and make it through the built in Authorize attribute without having to write anything custom.

Next, we will look at taking advantage of this CookieProvider in a .NET Signalr Client to use the full power and speed of web socket connections.

If you like what you see, don’t forget to follow me on twitter @Suave_Pirate, check out my GitHub, and subscribe to my blog to learn more mobile developer tips and tricks!

Onionizing Xamarin Part 6

For those who just want code: https://github.com/SuavePirate/Xamarin.Onion 

Don’t forget:

  1. Part 1 on the general project structure: Onionizing Xamarin Part 1
  2. Part 2 on our Domain and Application layers: Onionizing Xamarin Part 2
  3. Part 3 on our Infrastructure layer: Onionizing Xamarin Part 3
  4. Part 4 on our Client layer and Xamarin.Forms implementation: Onionizing Xamarin Part 4
  5. Part 5 on creating custom Platform specific logic: Onionizing Xamarin Part 5

A strong and scale-able architecture is important in applications, especially in Mobile Apps. APIs and SDKs are constantly changing, new technology is constantly released, and team sizes are always changing. A solid Onion Architecture can save a development team a lot of time by making it simple to change service implementations, restrict access to certain areas, making logic flow easy to follow, and making testing isolated blocks of code easier.

Some of the important topics this will cover:

  • Separation of Concerns
  • Inversion of Control
  • Dependency Injection
  • Model-View-ViewModel
  • Testability
  • Why all these things are important

Part 6

In this section, we will talk briefly about building useful tests for our solution, and why the Onion pattern makes it easy to break tests out into individual layers.

In this example, we will add a test project whose purpose it to just test the Business layer within our Infrastructure.

Tests.Business

Let’s start with by adding a nUnit project to our solution, or by adding the nuget package to a class library. Xamarin has great documentation on this:¬†https://developer.xamarin.com/guides/cross-platform/application_fundamentals/installing-nunit-using-nuget/

In our project, we also want to install MvvmLight, just like in our Client and Platform layers. We will also need to add references to our Domain.Models, Domain.Interfaces, Application.Models, Application.Interfaces, and Infrastructure.Business projects.

In order to test our Infrastructure.Business project, we will need to create mock versions of our Data project. In our test project, we can create Repository implementations with mock data for each set that we need. For example:

MockGenericRepository.cs

public class MockGenericRepository : IGenericRepository
{
    private List _data;
    public MockGenericRepository()
    {
        _data = new List();
    }

    public void Add(T entity)
    {
        _data.Add(entity);
    }

    public void AddRange(IEnumerable entities)
    {
        _data.AddRange(entities);
    }

    public Task CommitAsync()
    {
        return Task.FromResult(false); // we don't need to explicitly save changes
    }

    public Task FindAsync(Func<T, bool> predicate)
    {
        var entity =_data.Where(predicate).FirstOrDefault();
        return Task.FromResult(entity);
    }

    public Task<IEnumerable> GetAsync(Func<T, bool> predicate)
    {
        var entities =_data?.Where(predicate);
        return Task.FromResult(entities);
    }

    public void Remove(T entity)
    {
        _data.Remove(entity);
    }
}

and MockUserRepository.cs

public class MockUserRepository : MockGenericRepository, IUserRepository
{
    public MockUserRepository()
    : base()
    {
    }
}

Now that we have some mock implementations, we can set up our tests against our Business logic.

UserBusinessTests.cs

public class UserBusinessTest
{
    private IUserService _userService;

    [SetUp]
    public void StartUpIoC ()
    {
        ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
        SimpleIoC.Default.Register<IUserService, UserService>();
        SimpleIoC.Default.Register<IUserRepository, MockUserRepository>();

        _userService = SimpleIoC.Default.GetInstance();
    }

    [Test ()]
    public async void AddUserTest()
    {
        var result = await _userService.CreateUserAsync(new NewUser
            {
                Email = "test@test.com",
                FullName = "Testy McTest"
            });
        Assert.IsNotNull(result.Data);
    }
}

Now we can test against any of the business logic in our application with a mock layer. The same practice can be applied to test any other layer in the solution as well. The data layer can be tested by mocking the business layer, and so on.

Conclusion

Looking back at all of the components of our Onion Architecture, one might think, “Wow, that’s a lot of code to do a simple task”. It’s important to remember that this architecture is not for every project. It’s focus is on scalability and testability. If your project has the potential to grow into something quite complicated, with many developers involved, this type of solution might work best for you. However, if you’re working on something quick to get out the door, maybe getting right to the point is easier and best for you.

The best parts about the Onion Architecture are its abilities to make drastic changes to tools or services used, without having to rewrite anything but that components implementation as well as making it easy to test individual layers without affecting the others or using real data. It also allows for closer monitoring and management of the codebase; keeping people from making calls directly from one layer to another. The only thing you have to emphasize is, “Are you adding a reference to another project to get something done? If so, you might be doing it wrong”.

Onionizing Xamarin Part 5

For those who just want code: https://github.com/SuavePirate/Xamarin.Onion 

Don’t forget:

  1. Part 1 on the general project structure: Onionizing Xamarin Part 1
  2. Part 2 on our Domain and Application layers: Onionizing Xamarin Part 2
  3. Part 3 on our Infrastructure layer: Onionizing Xamarin Part 3
  4. Part 4 on our Client layer and Xamarin.Forms implementation: Onionizing Xamarin Part 4

A strong and scale-able architecture is important in applications, especially in Mobile Apps. APIs and SDKs are constantly changing, new technology is constantly released, and team sizes are always changing. A solid Onion Architecture can save a development team a lot of time by making it simple to change service implementations, restrict access to certain areas, making logic flow easy to follow, and making testing isolated blocks of code easier.

Some of the important topics this will cover:

  • Separation of Concerns
  • Inversion of Control
  • Dependency Injection
  • Model-View-ViewModel
  • Testability
  • Why all these things are important

Part 5

In this section, we will look at how to expand our Inversion of Control container with platform specific code. Specifically, we will implement some pieces of the HockeyApp SDK so that we can make calls to it from our Client or Infrastructure layers.

Our example will focus on just Android, but the same principles can be applied to any of the unique platform projects.

Platforms.Android

First thing we need to do is make sure we also install the MvvmLight nuget package in your Android project, as well as the HockeyApp Xamarin package.

From here, we can go back to our Application.Interface layer and create a new service:

ICrashAnalyticsService.cs

public interface ICrashAnalyticsService
{
    void Initialize();
    void GetFeedback();
}

Setting it up generic like this allows us to switch providers from HockeyApp to some other service should that be a need in the future.

Back in our Android project, let’s implement the ICrashAnalyticsServicewith our HockeyApp logic.

HockeyAppService.cs

public class HockeyAppService : ICrashAnalyticsService
{
    private const string HOCKEYAPP_KEY = "YOUR_HOCKEYAPP_KEY";
    private readonly Android.App.Application _androidApp;
    private readonly Activity _context;
    public HockeyAppService(Activity context, Android.App.Application androidApp)
    {
        _context = context;
        _androidApp = androidApp;
    }
    public void GetFeedback()
    {
        FeedbackManager.ShowFeedbackActivity(_context.ApplicationContext);
    }

    public void Initialize()
    {
        CrashManager.Register(_context, HOCKEYAPP_KEY);
        MetricsManager.Register(_androidApp, HOCKEYAPP_KEY);
        UpdateManager.Register(_context, HOCKEYAPP_KEY);
        FeedbackManager.Register(_context, HOCKEYAPP_KEY);
    }
}

Now we can create an IoCConfig class specific to our Android project. Because SimpleIoC uses a singleton for its container, we can register classes in our platform specific classes before our registrations in the Client layer.

AndroidIoCConfig.cs

public class AndroidIoCConfig
{
    public void RegisterAndroidServices(Android.App.Application application, Activity activity)
    {
        var hockeyService = new HockeyAppService(activity, application);
        hockeyService.Initialize();
        SimpleIoc.Default.Register<ICrashAnalyticsService>(() => hockeyService);
    }
}

Don’t forget to add a reference to the Application.Interfaces project in your platform project.

Lastly, let’s update our MainActivity to initialize our AndroidIoCConfig before we start up the ¬†Xamarin.Forms app:

MainActivity.cs

public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity
{
    protected override void OnCreate(Bundle bundle)
    {
        TabLayoutResource = Resource.Layout.Tabbar;
        ToolbarResource = Resource.Layout.Toolbar;

        base.OnCreate(bundle);
        global::Xamarin.Forms.Forms.Init(this, bundle);
        InitializeIoC();
        LoadApplication(new App());
    }

    private void InitializeIoC()
    {
        var container = new AndroidIoCConfig();
        container.RegisterAndroidServices(Application, this);
    }
}

Now we can make calls to our ICrashAnalyticsService from the Client layer, and use the Android specific logic. For example, we can pass the ICrashAnalyticsService into the constructor of a ViewModel, and call the GetFeedback() method to get access to the HockeyApp Feedback view.

ExampleViewModel.cs

public class ExampleViewModel : BasePageViewModel
{
    private readonly ICrashAnalyticsService _crashAnalyticsService;
    private ICommand _feedbackCommand;

    public ICommand FeedbackCommand
    {
        get
        {
            return _feedbackCommand ??
                (_feedbackCommand = new RelayCommand(() =>
                {
                    _crashAnalyticsService.GetFeedback();
                }));
        }
    }
}

It’s all that simple! The same pattern can be applied to anything that needs to be platform specific.

What’s Next

In the next and final segment, we will look at building mock implementation of our Infrastructure layer and using them to test layers individually in Unit tests.

Next: Onionizing Xamarin Part 6

Onionizing Xamarin Part 4

For those who just want code: https://github.com/SuavePirate/Xamarin.Onion 

Don’t forget:

  1. Part 1 on the general project structure: Onionizing Xamarin Part 1
  2. Part 2 on our Domain and Application layers: Onionizing Xamarin Part 2
  3. Part 3 on our Infrastructure layer: Onionizing Xamarin Part 3

A strong and scale-able architecture is important in applications, especially in Mobile Apps. APIs and SDKs are constantly changing, new technology is constantly released, and team sizes are always changing. A solid Onion Architecture can save a development team a lot of time by making it simple to change service implementations, restrict access to certain areas, making logic flow easy to follow, and making testing isolated blocks of code easier.

Some of the important topics this will cover:

  • Separation of Concerns
  • Inversion of Control
  • Dependency Injection
  • Model-View-ViewModel
  • Testability
  • Why all these things are important

Part 4

In this section, we will look at the code for our actual Xamarin.Forms client implementation along with talking about building other Non-Xamarin clients into our solution, and sharing as much code between them as possible. This are our Client layer, and will include setting up our Views, ViewModels, IoC container, and start up process.

Client Layer

First thing is first, let’s build our ViewModels. These ViewModels are going to interface with our Application layer by making calls to our defined Service Interfaces that will be injected into the constructors of our ViewModels.

Some things to note: We are using MVVM Light in this example to make our MVVM and IoC easier to get going. So things such as the ViewModelBase class and the Set() method are coming from that library. You can choose to utilize a different library, or roll your own pretty easily. In either case, the principles are the same.

Let’s first abstract some universal properties into a BasePageViewModel.cs

public class BasePageViewModel : ViewModelBase
{
    private bool _isLoading;
    private bool _isEnabled;
    private string _title;
    private ObservableCollection<string> _errors;

    public bool IsLoading
    {
        get
        {
            return _isLoading;
        }
        set
        {
            Set(() => IsLoading, ref _isLoading, value);
        }
    }
    public bool IsEnabled
    {
        get
        {
            return _isEnabled;
        }
        set
        {
            Set(() => IsEnabled, ref _isEnabled, value);
        }
    }
    public ObservableCollection<string> Errors
    {
        get
        {
            return _errors;
        }
        set
        {
            Set(() => Errors, ref _errors, value);
        }
    }

    public string Title
    {
        get
        {
            return _title;
        }
        set
        {
            Set(() => Title, ref _title, value);
        }
    }
    public BasePageViewModel()
    {
        IsEnabled = true;
        IsLoading = false;
    }

    public override void Cleanup()
    {
        base.Cleanup();
        Errors = null;
    }
}

 

From here let’s make a ViewModel for each of our pages (in this example, we will just look at one “MainPage”)

MainPageViewModel.cs

public class MainPageViewModel : BaseViewModel
{
    private readonly IUserService _userService;
    private string _bodyTitle;
    private string _bodyText;
    public string BodyTitle
    {
        get
        {
            return _bodyTitle;
        }
        set
        {
            Set(() => BodyTitle, ref _bodyTitle, value);
        }
    }

    public string BodyText
    {
        get
        {
            return _bodyText;
        }
        set
        {
            Set(() => BodyText, ref _bodyText, value);
        }
    }

    private async void Initialize()
    {
        IsLoading = true;
        await Task.Delay(2000); // simulate load time
        var users = await _userService.GetValidUsers();
        if(users?.Data == null || users.Data.Count() == 0)
        {
            var user = await _userService.CreateUserAsync(new NewUser
            {
                FullName = "Felipe Fancybottom",
                Email = "feffancy@fancybottoms.com"
            });

            BodyText = user.Data.Email;
            BodyTitle = user.Data.FullName;
        }
        else
        {
            BodyText = users.Data.First().Email;
            BodyTitle = users.Data.First().FullName;
        }
        IsLoading = false;
    }

    public MainPageViewModel(IUserService userService)
    {
        _userService = userService;

        Title = "Onion Template";
        BodyTitle = "Loading Name";
        BodyText = "Loading Email";
        Initialize();
    }
}

Notice how we injected the IUserService in the constructor, and use that to lazy load some data into our bindable properties. When we create our view and set the BindingContext to this ViewModel, we will see the UI automatically update when those do. This example does it async right from the constructor, but you can load your data and set up your initial properties any way you’d like.

The next step is to initialize our Inversion of Control, Dependency Injection, and ViewModelLocator to tie all our layers together and allow us to automatically set the BindingContext of our Page.

If it makes sense to you, you can break the IoC set up into a separate project that references all the previous layers. For the sake of simplicity, we are going to do it in the same project as our Xamarin.Forms project.

IoCConfig.cs

public class IoCConfig
{
    public IoCConfig()
    {
        ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
    }

    public void RegisterViewModels()
    {
        SimpleIoc.Default.Register<MainViewModel>();
    }

    public void RegisterRepositories()
    {
        SimpleIoc.Default.Register<IUserRepository, UserRepository>(); // this is where you would change the registration to use a different repository
    }

    public void RegisterServices()
    {
        SimpleIoc.Default.Register<IUserService, UserService>();
    }

    public void RegisterProviders()
    {
        SimpleIoc.Default.Register<IUserDataProvider, UserDataProvider>();
        SimpleIoc.Default.Register<ICloudStorageProvider, AzureStorageDataProvider>(); // this is where you would change the registration to use a different provider
    }

    public void RegisterStores()
    {
        SimpleIoc.Default.Register<IUserStore, UserStore>();
        SimpleIoc.Default.Register<IStoreManager, StoreManager>();
    }
}

The purpose of this class is to wire up our dependencies as well as our actual container for the ServiceLocator. This example is using SimpleIoc which is packaged with MVVM Light.

Now that we have our other layers glued together, we just need to create our ViewModelLocator to automatically handle our bindings, then make calls to the IoCConfig when the ViewModelLocator is initialized.

ViewModelLocator.cs

public class ViewModelLocator
{
    public MainPageViewModel MainPage
    {
        get
        {
            return ServiceLocator.Current.GetInstance<MainPageViewModel >();
        }
    }
    public ViewModelLocator()
    {
        var iocConfig = new IoCConfig();
        iocConfig.RegisterRepositories();
        iocConfig.RegisterProviders();
        iocConfig.RegisterServices();
        iocConfig.RegisterViewModels();
        iocConfig.RegisterStores();
    }
}

In our constructor, we initialize our IoC, and also provide properties for each of our ViewModels, so that we can bind it easily in our XAML.

The last two steps here are to add a Resource in our App.xaml to our ViewModelLocator, and create our Page.

App.xaml


<?xml version="1.0" encoding="utf-8"?>
<Application xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="OnionTemplate.App">
    <Application.Resources>
        <!-- Application resource dictionary -->
        <ResourceDictionary>
                <vm:ViewModelLocator xmlns:vm="clr-namespace:NAMESPACEOF.VIEWMODELLOCATOR;assembly=YOURPACKAGENAME" x:Key="Locator" />
        </ResourceDictionary>
    </Application.Resources>
</Application>

Now that we have our resource, let’s create our page and wire up the BindingContext in our XAML.

MainPage.xaml


<?xml version="1.0" encoding="UTF-8"?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="NAMESPACE.MainPage" BindingContext="{Binding Source={StaticResource Locator}, Path=Main}" Title="{Binding Title}">
    <ContentPage.Content>
        <StackLayout Orientation="Vertical" HorizontalOptions="Center" VerticalOptions="Center">
            <Label Text="{Binding BodyTitle}"/>
            <Label Text="{Binding BodyText}"/>
            <ActivityIndicator IsRunning="True" IsVisible="{Binding IsLoading}"/>
        </StackLayout>
    </ContentPage.Content>
</ContentPage>

There is nothing required to write in our code behind (MainPage.xaml.cs) since it is all automatically wired up.

Last but not least, set our page in our App.xaml.cs:

App.xaml.cs


public partial class App : Xamarin.Forms.Application
{
    public App()
    {
        InitializeComponent();

        MainPage = new NavigationPage(new MainPage());
    }
}

At this point, we should be able to run the application (assuming that the Xamarin.Forms app is started off in each platform the way the template sets it up).

So we have our Xamarin.Forms implementation. But what about other applications that can’t use Xamarin.Forms? Web apps? Xamarin.Mac apps? Cloud apps? WPF?

Here is one of the coolest parts of the entire Onion pattern. We can go ahead and add more projects into our Client layer. These layers can use the same models, interfaces, and in some cases, implementations! For projects where we would need completely different logic, such as a Web App for example, we can implement multiple versions of the Domain and Application layers.

In our web app, we could create another project in the Infrastructure layer (say Infrastructure.WebData) that uses Entity Framework and SQL. Then in our IoCConfig of our Web App, we call to register our Infrastructure.WebData implementations for our Domain.Interfaces.

As long as each project in the Client layer serves the same purpose of configuring Views, and starting up our application with our Inversion of Control, any type of application can live here and follow the same pattern.

The Client layer can also contain abstractions of controls or other utilities that can be referenced by the core Client projects.

What’s Next

In the next segment, we will look at how to integrate our individual mobile platforms, and how to inject custom platform-specific code with some examples using the HockeyApp SDK.

 

Next: Onionizing Xamarin Part 5