Don of the Day

Don of the Day


Adventures in software development with Xamarin and the Web

Software developer, building things with code in sunny Scottsdale, AZ.

Share


Twitter


Dot Net Core Tech Stack

Don FitzsimmonsDon Fitzsimmons

New tools for a new startup.

It's been a while since I've posted here. Hey, lay off, I've been busy. Anyway, I'm working on a new startup, my own startup, and let me tell you, I spent a lot of time researching and choosing my tech stack. As a .Net developer, of course I figured I'd go with what I know and just pump out a typical .Net app using the usual suspects like Entity Framework, MSSQL Server, ASP.Net Web API and ASP.Net MVC. But, what's the fun in that? There's so much new stuff in the .Net world that it was time to take a risk with this project and use the latest and greatest.

The App

Before I get into the technical stuff, allow me to first introduce the app. It's really much more than an app, it's a marketplace for buying and selling used camera gear. I'm a big photography nerd and I buy and sell used gear often. Lot's of people do this. But there's no dedicated, peer-to-peer marketplace for camera gear, so my business partner and I are creating it. You can learn more here. Needless to say, this app will be a big, complex system involving fairly large financial transactions so it's got to be rock solid. It's going to have a Web front-end, a Web API and both iOS and Android apps. Lot's of work ahead. Back to the technical stuff.

The Platform: Dot Net Core

This was really a no-brainer. About a year ago I switched from Windows to macOS because I was primarily doing Xamarin development (still am). So, now that I could write C# on my Mac using either Visual Studio for Mac, or Visual Studio Code, using dot net core, that was a strong mark in its favor. But, the fact that I could host my app on a Linux server sealed the deal for me. I like having that flexibility and I'm a fan of Digital Ocean's hosting.

The development experience has been good. It was a bit rocky at first, but things are working nicely. I find myself going back and forth between Visual Studio Code and VS for the Mac. VS for the Mac is more feature-rich, but it's also less stable and more clunky feeling. VS Code feels fast and light but lacks certain features. I'm sure VS for Mac will become better as time goes on.

The Data Layer

This is the only part of the app that's settled and under active development currently. Because I'm building this app with dot net core, I didn't want to be stuck using Microsoft's database even though it can be run on other platforms now. I have always wanted to use PosgreSQL and it seemed like a good fit for my app because I also wanted to use a document database, which Postgre is. Also, I really don't like Entity Framework...actually, I really don't like the ORM concept. It's clunky and the thought of using the repository pattern makes my stomach turn.

My quest to avoid an ORM led me to one of the coolest .Net libraries I've seen in a long time. It's called Marten and it's awesome. Have I mentioned this library is great? Okay, enough gushing. So, I'm using Marten and I'm also using the Command and Query Responsibility Segregation (CQRS) pattern. It feels so much cleaner than the old, rusty repository pattern. With CQRS, I can write some nice generic queries and commands that look like this:

A Command:


public class SaveDocumentCommand : ISaveDocumentCommand where T: DocumentBase
    {
        private IDocumentSession _session;
        public T Entity { get; set; }

        public SaveDocumentCommand(IDocumentSession session)
        {
            _session = session;
        }
        public async Task ExecuteAsync()
        {
            if (Entity == null)
                throw new ArgumentException("Entity can't be null when calling Execute");

            _session.Store(Entity);

            await _session.SaveChangesAsync();

            return Entity.Id;
        }
    }

A Query:


public class DocumentQuery : IDocumentQuery where T : DocumentBase
    {
        private IDocumentSession _session;
        public Guid Id { get; set; }

        public DocumentQuery(IDocumentSession session)
        {
            _session = session;
        }

        public async Task ExecuteAsync()
        {
            if (Id == Guid.Empty)
                throw new ArgumentException("Id is required to query an entity");

            var entity = await _session.Query().Where(x => x.Id == Id).FirstOrDefaultAsync();

            return entity;
        }
    }

Adapting my mindset to using a document database vs. relational has been a challenge, but after some time, I feel like I really get it now. It took a while to click.

The Business Layer

I'm using a pretty thin business layer. It mostly performs validation using Fluent Validation, another great library. This layer will eventually be responsible for handling more complex business rules related to financial transactions and hopefully, real-time communication using SignalR. For now, it just ensures that the incoming data is correct.

The Web Stuff

This is an area that's still undecided, but I'm leaning toward making my web UI a SPA with either Aurelia or Angular, but I'm not totally sure yet. I do know that no matter what I do, I'll need a web API and as you may know, I don't like ASP.Net Web API because it does very little for me. I have searched high and low for a better web API framework and I finally found one that looks promising. JSON API .Net Core fulfills most of my wish list for a framework. Originally it only worked with Entity Framework, but that has recently changed allowing it to work with my custom business layer (I hope). I'll be writing about my experience with this library as I get deeper into it, but my hopes are high.

The Mobile Apps

Coming from a guy who specializes in Xamarin, this is pretty obvious. I'll be using Xamarin.Forms for the mobile apps. There's so much new Xamarin stuff that's come out lately, I'm really looking forward to using things like the live preview. This app will be very feature-rich and I want it to have the same functionality as the web app. Lots of challenges to come.

Anyway, that's what I've been up to. It's early in the development cycle, but I'll be sure and write about the experience more as I progress.

In the meantime, check out my app if you haven't already.

Software developer, building things with code in sunny Scottsdale, AZ.

Comments