Exposing your XPO ORM using GraphQL dotnet

by Joche Ojeda | Apr 22, 2019 | DevExpress, GraphQL, XPO

Exposing your XPO ORM using GraphQL

Note: you can download the full source code for this article in my GitHub repository

In the past few years, I have been working on developing mobile applications, in the mobile world most of the applications will consume some type of data service, the main problem here is how to choose the correct data service? There are a lot of technologies to expose data over the wire and all of them are good somehow, so for me, the quest is about to find a technology where can I use my current skill set.

Today subject of study is GraphQL, an open source technology developed by Facebook that is a data query and manipulation language for API.

The beauty of GraphQL is its efficient and flexible approach to develop web APIs that can be queried to return a different data structure in the opposite side of the REST API and traditional web services that return a fix data structure, you can learn more about the GrahpQL project on their website https://graphql.org/

First, we will start by creating a new Asp.net core web application

We name the application

Then we select Empty for the project type

Now that the project is created, we need to add a few NuGet packages, you can copy and paste the following snippet inside of your csproj file

<ItemGroup>

<PackageReference Include="DevExpress.Xpo" Version="18.2.7" />

<PackageReference Include="GraphQL" Version="2.4.0" />

<PackageReference Include="GraphQL.Server.Transports.AspNetCore" Version="3.4.0" />

<PackageReference Include="GraphQL.Server.Transports.WebSockets" Version="3.4.0" />

<PackageReference Include="Microsoft.AspNetCore.App" />

<PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />

<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.2.0" />

<PackageReference Include="Microsoft.Data.Sqlite" Version="2.2.4" />

<PackageReference Include="System.Reactive" Version="4.1.5" />

</ItemGroup>

Now if let’s try to compile and run the application, at this moment you should see a “hello world” in your browser

Now let’s add a second project to the solution to host the ORM, for that let’s use a NetStandard class library

Let’s name the project XpoOrm, then edit the project file and add the following NuGet packages

<ItemGroup>

<PackageReference Include="DevExpress.Xpo" Version="18.2.7" />

<PackageReference Include="GraphQL" Version="2.4.0" />

<PackageReference Include="GraphQL.Server.Transports.AspNetCore" Version="3.4.0" />

<PackageReference Include="GraphQL.Server.Transports.WebSockets" Version="3.4.0" />

<PackageReference Include="System.Reactive" Version="4.1.5" />

</ItemGroup>

Now let’s add 3 folders, schema, services and models

The basic structure of our project is ready, so let’s start adding some models, we will add 2 models products and categories, you can get the source of the files here

When you finish implementing the models the next step is to implement the services, remember that the main goal of GraphQL is to create a queryable layer between the client and the data service, you can architecture your service in the way that is more convenient for you but in this case I will create one service per entity, this services will be injected in our application using asp.net dependency injection. You can find the source for the services here

Product Service

Category Service

So far there we have not written any code related to GraphQL so now it’s the time. GraphQL does not directly expose your data model class instead it builds a type based on your model, let’s see how this will work for the Category model

As you can see, I have created a new class that inherits from ObjectGraphType<T> where T is our XPO persistent class. Also, in the constructor I used the fluent API to map the fields from the category model to the CategoryType class, the method Field contains several overloads so you can do any type of crazy stuff in here, but for now I’m going keep it simple, now lets create the type for the product model.

Now that we have created the ProductType class we can see that there are new characteristics here, the first new thing that you will notice is that in the constructor I injected the category service to load the category object related to the product, that is the common design pattern of GrahpQL, this approach is useful if you are using POCO objects. Also, if you see the commented-out code you can see that when we use XPO we don’t need to inject the category service since it can be loaded directly from the instance of the Product class using XPO lazy loading feature. You can find both graph types here

Now that we have our graph types, we need to create 2 more classes, an object that will hold our list of queries and a schema object that will provide information about the types and the queries that we are exposing, let’s start with the queries object

The Queries object is basically another graph type, but instead of exposing a model class is exposing the object class, it also uses the dependency injection to inject the 2 services that will forward the data to the fields. Now its time to create the schema for our GraphQL service

A GraphQL schema can only expose one query so that is why I have created the object queries to hold all the possible subqueries of our services. As you can see, I injected the queries object and the dependency resolver, you can find the code for these classes here.

Now its time to go back to the asp.net core service and start the configuration of GrahpQL, let’s start with the program class

As you can see in the main method there is some boilerplate code to initialize XPO data layer and create some sample data, nothing new if you are an XPO user you might be already familiar with this code. Now let’s move to the startup class

As any asp.net core web application, there are 2 important methods let’s see what happened on each of them.

In the configure services method I register the services I created and the graph types also added the GraphQL service and the web sockets and data loader.

Now in the configure method I enabled the use of default files and static files, web sockets also I exposed the GrahpQL schema using web sockets and GrahpQL (this is the HTTP version of the API)

Our API is almost done, there is only one last step we need to do, we need a way to test our API for that we will use Graphical which is a web client to query GrahpQL APIs, the graphical project is hosted here https://github.com/graphql/graphiql but to make it simpler you can download the files from my GitHub repository here

Let’s create a wwwroot folder and add the graphical files into it

Run the application, you should see the graphical U.I and you should be able to navigate the API documentation

or you can query of XPO ORM

As you can see there is autocomplete on the query editor also we are able to query objects and nested objects on a field-based manner

This article is the first article on a series of how to expose any XPO ORM using GraphQL, in the next post we will learn about mutations

Xamarin & XPO System.NotSupportedException: Encoding 1252 data could not be found. Make sure you have correct international codeset assembly installed and enabled.

by Joche Ojeda | Apr 18, 2019 | Forms, Xamarin, XPO

You know that moment when you are about to deliver your next mobile app, everything is working fine in your development environment but once you release the app to your customers you start getting errors like the one below

You think, what happened? everything was running fine on my development environment. Well, lets said that when you compile your Xamarin application the main goal of the compiler and the linker is reduced the size of the app, so a lot of things get stripped out of the final release.

Some of the things that are stripped out of the final release are the code pages and that can cause crashes in your app not because your code depends on them but because of some nugets or third-party libraries do.

So to avoid having the exception “System.NotSupportedException: Encoding 1252 data could not be found. Make sure you have correct international codeset assembly installed and enabled” you just need to explicitly add code page to your application

For iOS projects, include it by checking west under Project Properties -> iOS Build -> Internationalization:

For Android projects, include it by checking west under Project Properties -> Android Build -> Linker -> Internationalization:

For visual studio for windows here are the screenshots

iOS

Android

The credit goes to this post, that saved my life fixing this error StackOverflow

XPO para Xamarin Forms, May 15 2019 (Lenguaje Español)

by Joche Ojeda | Apr 16, 2019 | DevExpress, Webinars, XPO

En el seminario web, aprenderá a aprovechar los conocimientos existentes de XPO y a usarlos para desarrollar aplicaciones móviles con Xamarin Forms

Fecha

Miercoles 15, 2019, 10:00 A. M hora de los Angeles (UTC-7)

Duracion

3 Horas

Lenguaje

Español

¿Qué obtendrá después del webinar?

Acceso al repositorio privado de GitHub con ejemplos de código para cada tema
La sesión de Webinar grabada

Lista de temas

Instalación de XPO para Xamarin Forms (Android e iOS)
Inicializar la base de datos local y el esquema
Conexiones locales con SQLite: instalación de paquetes necesarios para Android e iOS
Conexiones locales con XML: creación de un archivo XML base
Conexiones remotas: conexión de base de datos directa con TCPIP (red LAN)
Conexiones remotas: la capa de acceso a datos de WCF
Inicializar la capa de datos
Enlace (binding) de datos MVVM
Enlace de propiedades primitivas
Enlace de propiedades de navegación
Cargando colecciones (la forma tradicional)
Cargando colecciones asincrónicas
Cargando un solo objeto de forma asíncrona
Las paginaciones en colecciones
Como reducir la carga de datos con XPView
Colecciones observables con BIT. Xpo. observables

Requisitos previos

Comprensión básica de Xamarin Forms
Comprensión básica del patrón de diseño MVVM
Conocimiento básico de XPO

Precio

€99,00 EUROS

[wpecpp name=”xamarin xpo es” price=”99.00″ align=”left”]

Nota

Si está interesado en este curso o tiene alguna duda póngase en contacto con nosotros en training@bitframeworks.com

BIT.Xpo.Observables Nuget

by Joche Ojeda | Oct 8, 2018 | Nuget, Xamarin, XPO

An observable implementation of XpCollection and XPPageSelector.

After 15 years, DevExpress has finally made XPO available free-of-charge. If you’re not familiar with XPO, you can learn more about its feature set here. If you’ve used XPO in the past or are familiar with capabilities, you will love this.

As we already know a Xamarin ListView is populated with data using the ItemsSource property, which can accept any collection implementing IEnumerable but if we want the ListView to automatically update as items are added, removed or changed in the underlying list, you’ll need to use an ObservableCollection. Here is where XpoObservableCollection becomes the best friend for all the XPO fans out there.

XpoObservableCollection inherit from an XPCollection so to use, it is exactly as you would use an XPCollection, the only difference is that the XpoObservableCollection refresh the state of ListViews on Xamarin Forms.

XamarinXpoPageSelector takes it a step further by internally implementing XPPageSelector and presenting the XpoObservableCollection as a pageable collection. With this in mind, on the constructor of the XamarinXpoPageSelector you need to pass the following parameters:

SortingCollection sorting = new SortingCollection();
sorting.Add(new SortProperty("Your Property", SortingDirection.Ascending));
XPCollection <Your Class> Collection = new XPCollection <YourClass>(UnitOfWork);
Collection.Sorting = sorting;

XamarinXpoPageSelector <YourClass> selector = new XamarinXpoPageSelector <YourClass> (Collection,10, XpoObservablePageSelectorBehavior.AppendPage);
       
this.listView.ItemsSource = selector.ObservableData;

Collection = An instance of XPCollection.
10 = Page Size by default.
XpoObservablePageSelectorBehavior = AppendPage or SinglePage.

Use Append in case you want to add the results of the new page to the collection or Single page to clear the last page results before showing the new page.

And that’s it. The same awesome ObservableRangeCollection (from MVVM Helpers) that adds important methods such as AddRange, RemoveRange, Replace, and ReplaceRange, it is now available in XPO and of course, it is open source so go and take a look behind the curtains.

https://github.com/egarim/BIT.Xpo.Observables

https://www.nuget.org/packages/BIT.Xpo.Observables/

Until next time. Xpo out!

XPO and database replication

by Joche Ojeda | Oct 7, 2018 | XPO, XPO Database Replication

After 15 years of working with XPO, I have seen many tickets asking if XPO is capable of doing data replication and all the time DevExpress team answer those tickets saying that replication its out of the scope of XPO and that it’s actually true.

So, to start talking about database replication lets try to define what “replication” means. Here is the definition of replication according to Wikipedia

“A computational task is typically replicated in space, i.e. executed on separate devices, or it could be replicated in time, if it is executed repeatedly on a single device. Replication in space or in time is often linked to scheduling algorithms”

The keywords on the above statement are task, space and time, so to replicate a database operation we need to know the following information

What was the task?
Who performed the task?
When was the task performed?
Who needs to know about the task what was performed?

Now let’s think what are the steps that any traditional database does, in order to replicate the data between instances

It shares a copy of the database schema to the other instances/locations/devices
It logs the DML statements that happened to a main instance/location/device
It broadcast the statements on this log to the other instances/locations/devices
it processes the statements on the target instance/locations/devices

Now the question is, can we do the same with XPO?

thanks to the great architecture develop by the XPO Team, the answer is a big YES!!!

so, let’s compare how you can match traditional database replication with XPO

	Traditional database replication	XPO database replication
1	Share a copy of the database schema.	In XPO we can re-create a database schema using the method UpdateSchema from the Session class.
2	Logs the DML statements.	In XPO we can keep track of the BaseStatement at the DataLayer level.
3	Broadcast the statements	We can transport the log of statements using any of the dot net network technologies like WCF, remoting or Web API.
4	Process the statements on the target instance, device or location	To process any kind of BaseStatement we can use the XPO DataLayer on the target instance, device or location

So, it looks like DotNet and XPO provide us of all the necessary infrastructure to do a database replication so why not give it a try right?

XPO POST 5: Layered Architecture

by Joche Ojeda | Oct 1, 2018 | DevExpress XPO from step 1 to N, XPO

There is nothing than inspire me more to write a blog post that a regular Saint Petersburg day and by regular, I mean windy, cold, dark and rainy, but don’t get me wrong I love this city but when the weather is too nice as it was this past summer is hard to focus on writing.

So, let’s get started with the post number 5, today we are going to talk about the architecture of XPO.

If you are new to XPO you might find that the documentation is sometimes overwhelming especially because most of the articles blogs and tickets are written in totally different times and versions of XPO, so you might find some really old blog post where the WCF scenario is not supported and the XpoProviders are tightly coupled with the DotNet ADO Providers and some other cases where is the opposite case.

XPO is now 15 years old and its architecture has changed since the early versions, most of the time when you find documentation about XPO layer architecture you won’t be able to see all the layers at once.

After spending 1 month and Gilbert Arizona, developing software side by side with my dear friend and student Jose Javier Columbie and having endless technical conversations about XPO, I realize that it is not easy to explain how the XPO architecture works, so I decided to draw the XPO architecture in a formal document. Javier also drew the first version of this diagram on his notepad and as always half in Spanish and half in English as we tend to do as Latin Americans.

So, without further due, here I present you the XPO architecture diagram

If you want to get a copy of the diagram with clickable links, you can download it here [download id=”172″]

Now let’s start explaining from left to right.

Persistent Classes: this layer is basically defined by you as the programmer and is nothing more than the persistent classes you write to abstract business objects. Usually, this layer is your starting point as an XPO user, so I won’t go into deeper detail since if you are reading this post you already know how this layer works.

Data Access, Data Cache and Data Filtering: in this layer, the most basic object is the session also is the base class for all the other objects in this layer. A session is basically a cache of all the persistent objects that have been instantiated since you start manipulating your DataStore or the objects that you have queried in your DAL (Data Access Layer).

Most of the behaviours from the session are passed to its child classes, won’t explain the difference on the child classes in this article but for sure it will be on my list of topics for the following weeks.

Object Access Layer: this layer is the bridge between the session and the actual DataStore. So basically, it works as a translator for the CRUD operations done in an object-oriented manner to statement objects that will be processed in the data access layer level.

Data Access Layer: is the bridge between the object access layer and the data stores (classes that implements IDataStore) and its basically in charge of pass the statement objects to the data store so it can translate it to the proper SQL statements for a specific database like MS SQL Server, Postgres, Mysql, etc.

Data Store Layer: is the lowest layer of all and it’s in charge to translate the statement objects to DDL and DML SQL statements and execute them at the database level using ADO.

Also, as you can see in the diagram this layer can be transferred over the wire using WCF to extend the functionality on the communication with the database. Using WCF is really useful if you don’t want to expose the connection string on the application config or if you want to transport the communication to the database in any of WCF supported network protocols.

« Older Entries

Next Entries »