asp-net-core Archives - CodeJourney.net

Xamarin.Android – ASP.NET web api synchronization – research

Dawid Sibiński — Wed, 27 Sep 2017 06:00:45 +0000

As you may know, in my MoneyBack Xamarin.Android application I’ve used SQLite as the local db management system. Recently I’ve added an ASP.NET Core web solution to my GitHub repository in order to create back-end API for my mobile app. I wanted to have database hosted on a remote server and Android application to synchronize its data with it.
Then I started wondering… and decided to make a deeper research first. As I wrote in my post summing up DajSiePoznac2017 competition, “before using a particular solution for an issue” we should “better examine the other possibilities” first. So I do

Why to synchronize with remote database?

First question to ask is why to synchronize with a remote database at all?

There are a few obvious advantages:

(+) users’ data is stored “in a cloud” and can be accessed from any device

(+) users don’t need to worry about backing-up their data

(+) data storage logic is moved to the web part of the system and with API exposed it can be easier to port it to other platforms

(+) having web API, a web client can be easily added to the system.

However, there are also some harms:

(-) synchronization of local and remote data (online and offline) must be handled

(-) synchronization uses some network data and battery of a mobile device

(-) web API must be maintained and after each change in it mobile app must be adjusted.

Despite all these aspects I’ve been wondering to implement a web API for few different reasons. First of all this could be a great programming experience, very interesting from architectural point of view. Secondly, I think this is a bit old-fashioned and messy that a user needs to export some database/app files backup to his GDrive in order to not lose his data.

Frankly, I just want to have some fun with ASP.NET Core, implement a web API and make MoneyBack working with it Maybe some Linux deployment after all? Let’s create some nice programming playground here

How to synchronize with web API?

That’s the question I’ve been searching an answer for recently. Long story short, the idea is to have a back-end database management system hosted on a web server and mobile app having its own local “mirror” of the database, bidirectionally synchronizing local data with remote database through web API. Mobile app should work in offline-first mode, which means that all operations must be possible to be done locally and potential (not mandatory) synchronization to happen as soon as it’s possible (user is connected to WiFi, has mobile network access etc.)

There are various possibilities and solutions to handle synchronization of mobile app’s data and remote database storage, from synchronization system built from scratch to Azure cloud hosting.

Custom synchronization mechanism

We could of course implement our own data synchronization mechanism. There are many tutorials available, including for instance this one, which describes all the contents quite nicely and I recommend reading it even if you don’t want to implement sync on your own – it helps understanding all the concepts.

Custom synchronization can be a lot of fun, but… why to reinvent the wheel?

Azure Mobile App Service

Microsoft’s Azure Mobile App Service is recommended almost everywhere – on StackOverflow, in the official Xamarin documentation and on a lot of blogs, but its free plan seems to not be worth using (except of performing some simple tests) while paid plans are more enterprisy. It seems great, but for my playground I neither want to pay nor use free plan which may become unusable after re-implementing the whole back-end.

Realm.io

Finally, out of a sudden, I found it. Realm.io is a totally separate database system built especially for mobile solutions. Its Mobile Database may be used as the db framework for a mobile app (Xamarin is also supported), replacing for instance SQLite. After all, Realm Mobile Platform can be used on a server-side handling mobile/web APIs and data synchronization – documentation says it supports .NET Core 1.1. Let’s hope they add support for 2.0 soon.

What’s more it’s all open-source and provides really nice free plans.

Realm.io looks very promising. I’m just a bit worried it’s almost never recommended on the web – is there something wrong with it? Maybe it’s a new stuff? Where’s a catch? Let me know if you’ve had any experience with it.

SQLite-sync.com

Last but maybe not least, I found SQLite-sync.com. The idea seems to be similar to Realm.io, however this product looks less mature. Not even 100 commits on their GitHub with just few contributors. Looking poor compared to Realm.io’s GitHub with more than 2.5k commits only for its .NET component.

The main (and the only?) benefit of using it would be the possibility to keep SQLite database in Xamarin.Android app. Apart from that, I don’t see any dominance over Realm.io.

Summary

As my research shows there are a lot of existing frameworks that help keeping data synchronized between mobile app and a remote back-end, allowing Xamarin app to work in offline-first approach. Microsoft offers great stuff in Azure, but in my opinion it’s not worth investing money for small playground apps.

For the moment I’m for Realm.io. It seems to provide very extended free plan, there’s a lot of resources on the web, folks talk about it on SO…

So now I’m asking you – do you have any experience with data sync in Xamarin apps? If yes, please share your insights and help me to choose the best approach

I’d be grateful for any suggestions!

After the framework is chosen, I will try to design the whole synchronization system and share it with you here.

The post Xamarin.Android – ASP.NET web api synchronization – research appeared first on CodeJourney.net.

Entity Framework Core – database initialization with Unit Test

Dawid Sibiński — Thu, 27 Jul 2017 19:15:59 +0000

I’ve recently been presented a concept of initializing the database (creating or re-creating it) with Unit Test method. Initially I thought it’s a non-sense, but after a while of taking a deeper look…

Code First approach

The method of initializing the database I mentioned was used with Entity Framework Core in ASP.NET Core project, where Code First database creation approach was used. As you know, this approach implies that we create models (classes) representing our database entities in the code first and then, using an ORM system (such as EF), database structures are created.

This is very convenient, especially in prototyping. I’ve developed few small or average-size ASP.NET apps and I always used Code First. However, I cannot say how it works on production as these apps were university or pet projects which I’ve never deployed on real customer’s environment. What I noticed is that creating entities using this approach is fast and quite easy.

Database initialization in development phase

As long as your project is in development phase, different developers are working on it and there is some database behind, but the data itself is not very important (you only need the database structure – there’s no production data in it yet), programmers often need to have the database (re)created. To make this process quick and easy, instead of using Migrations straightaway, you can define your models, DbContext and write a Unit Test method which initializes the database. Then, each developer working on the project only needs to re-run this Unit Test to have the database created.

What’s more, as soon as another programmer makes any change in any of the models, the others just need to re-run the Unit Test which re-creates the database and potentially fills it with sample data. There’s no need to keep any migration files/scripts in the development phase.

The following subsections present how to do that.

Examples are based on a simple ASP.NET Core MVC application called CarServiceMvc. I’ve used .NET Core 2.0 Preview 2 and Visual Studio 2017 15.3.0 Preview 3.0.

The whole source code is available on GitHub.

Models

First, let’s create a simple model in our application. The following class is created in Models folder:

	public class Car
	{
	public int Id { get; set; }
	public string Producer { get; set; }
	public string Model { get; set; }
	public DateTime ProductionDate { get; set; }
	public bool IsOnWarranty { get; set; }

	}

view raw

Car.cs

hosted with ❤ by GitHub

DbContext

Next, let’s add CarServiceContext to our application. Let’s store it in ORM folder.

	public class CarServiceContext : DbContext
	{
	// DB connection properties injected automatically
	public CarServiceContext() {}

	// DB connection properties given explicitly (for Unit Tests)
	public CarServiceContext(DbContextOptions options) : base(options) { }

	public DbSet Cars { get; set; }

	}

view raw

CarServiceContext.cs

hosted with ❤ by GitHub

Constructor taking DbContextOptions has been created for Unit Tests purpose.

We also have a DbSet of Cars.

We also need to add a connection string to appsettings.json. For the development phase we can use mssqllocaldb included within Visual Studio:

	{
	"Logging": {
	"IncludeScopes": false,
	"Debug": {
	"LogLevel": {
	"Default": "Warning"
	}
	},
	"Console": {
	"LogLevel": {
	"Default": "Warning"
	}
	}
	},
	"ConnectionStrings": {
	"DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=aspnet-Demo;Trusted_Connection=True;MultipleActiveResultSets=true"
	}
	}

view raw

appsettings.json

hosted with ❤ by GitHub

In the end, Startup.cs should be modified to have our DbContext registered:

	public void ConfigureServices(IServiceCollection services)
	{
	services.AddDbContext(o =>
	o.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
	services.AddMvc();
	}

view raw

Startup_dbContext.cs

hosted with ❤ by GitHub

Now we can add a new controller for the Car model we created, so Visual Studio scaffolds all basic views. However, if we try to launch the application calling one of CarsController‘s methods, we get the following exception:

Car not found

So, let’s see how we can initialize our database with Unit Test.

Database initialization Unit Test

Firstly, new project should be added to our solution. Let’s add a new one of type Unit Test Project (.NET Core) and call it CarsServiceMvc.Tests.

We would like to use DefaultConnection connection string defined in the main project. For that purpose, we right click on the Tests project, select Add -> Existing item …, go back to the main project’s folder and select appsettings.json file, adding it as a link:

Adding config file as a link

This file should also be copied to the output directory of Tests project (it can be set in the Properties of the linked file).

Now we can add a new TestClass called CarServiceContextInitTests which will contain our db initialization Unit Test. In order to be able to access the same database as in the main project, we need to create few properties and configure necessary settings in the constructor of the test class:

	[TestClass]
	public class CarServiceContextInitTests
	{
	// to have the same Configuration object as in Startup
	private IConfigurationRoot _configuration;

	// represents database's configuration
	private DbContextOptions _options;

	public CarServiceContextInitTests()
	{
	var builder = new ConfigurationBuilder()
	.SetBasePath(Directory.GetCurrentDirectory())
	.AddJsonFile("appsettings.json");

	_configuration = builder.Build();
	_options = new DbContextOptionsBuilder()
	.UseSqlServer(_configuration.GetConnectionString("DefaultConnection"))
	.Options;
	}
	}

view raw

CarServiceContextInitTests_ctor.cs

hosted with ❤ by GitHub

As the appsettings.json file is copied to the Tests project’s output directory, we can read its contents with ConfigurationBuilder class. After, we just initialize _options property with the db connection settings.

Finally we can add the desired Unit Test method:

	[TestMethod]
	public void InitializeDatabaseWithDataTest()
	{
	using (var context = new CarServiceContext(_options))
	{
	context.Database.EnsureDeleted();
	context.Database.EnsureCreated();

	var car1 = new Car()
	{
	Producer = "Volkswagen",
	Model = "Golf IV",
	ProductionDate = new DateTime(2009, 01, 01),
	IsOnWarranty = false
	};

	var car2 = new Car()
	{
	Producer = "Peugeot",
	Model = "206",
	ProductionDate = new DateTime(2000, 01, 01),
	IsOnWarranty = false
	};

	context.Cars.AddRange(car1, car2);
	context.SaveChanges();
	}
	}

view raw

InitializeDatabaseWithDataTest_method.cs

hosted with ❤ by GitHub

There are few important parts of this code:

Line 4: we used _options property to configure the CarServiceContext thanks to its second constructor

Lines 6 and 7: EnsureDeleted() method is called before EnsureCreated(), which makes the db being re-created every time Unit Test is run.

After, there’s just creation of two Car objects and inserting these into the database.

After this Unit Test is run, Cars table is created in the local database with two sample rows. When we launch the application there’s no more error:

Cars list

From now on, every developer who starts working on the project only executes our unit test and his/her local database is created and filled with sample data.

Moreover, when there’s any change in the model class, there’s just one Unit Test to modify (e.g. if Required column is added to the model) and the other programmers just re-execute the Unit Test and database is up-to-date and ready to work with.

Database initialization on production

The Unit Test approach of database initialization could also be used on production environment, for instance when the application is to be installed for the first time on customer’s environment. We can create another Unit Test which creates the database structures, but doesn’t fill it with any data in a separate project. Then such Unit Tests project can be compiled to an executable and launched on production environment.

I know people who used it on production, but I don’t think I’ be brave enough to go that far

Summary

The database initialization with Unit Test is kind of a new approach I’ve never been thinking about. In my opinion it could be used with success during development phase, when the data in the database is not a production one. As soon as customer starts creating some business data in the application, it would probably make less sense to drop and create brand new database each time a developer starts working on the project (most of the bugs/issues we solve on production are dependent from the business data in the application).

Did you know this approach of creating the database with Unit Test? What are the techniques you use to initialize the database when working with other developers? Let me know, I’m deeply interested how it looks on your daily basis

The post Entity Framework Core – database initialization with Unit Test appeared first on CodeJourney.net.