As I See Tech

Empowered with a " template " to define the CRUDS interface method signatures, thanks to the ResultInfo class and .Net's dynamic types, I can quickly complete my interface designs.

One of the problems with trying to define interface method signatures is that it can involve a lot of guesswork and, therefore, a lot of risks. At design time, you can only assume so much. A few months after, it's possible that you'll encounter scenarios that might not be supported. Signatures that are not good enough is an interface designer's nightmare. Years down the line, changing an interface is like declaring war!

In the previous series , I talked about how I was able to put together database context and "repository" classes for what the team calls the new "core architecture". In Part 4 of that series, I mentioned about the CRUDS interfaces, but I did not expand on them. This new series covers the CRUDS interfaces themselves, and how they can be used to complete the repositories.

A new "core architecture" has been defined for the team. IDbDataContext and DbRepositoryBase are designed to shield the applications from the data source and from the underlying technologies of the data layer. As far as the applications are concerned, they know only of the POCOs and the repositories.

So far, I have the POCOs and the database context. If I let the application access the database context directly, it binds the application to the database context. This breaks the goal of making sure that the application is data store agnostic. What's needed is a mediator between the database context and the application itself.

The team decided that they would create POCOs to represent data models. It is the first step to making applications data source agnostic. The second step is to actually define the objects that would shield applications from the data source.

It's time to replace a 10 year old "core architecture" with a modern version. The team decided on continuing to use stored procedures with the intent of keeping all business rules and logic in one place. Instead of going for Microsoft's Entity Framework, the team opted to use Dapper, a micro-ORM with lots of promise.

When I got myself in to writing a new library for data access layers, NOT choosing Microsoft's Entity Framework was an easy decision. Likewise, micro-ORM Dapper, was an easy choice.

There was a time when the Singleton pattern was a trend... until it was officially declared an anti-pattern.

In a world filled with jargons, software developers never run out of new ones. MVC, ORM, UoW, SPA, SignalR, GitHub, NuGet, DevOps, etc. If you don't catch up, you can get lost in figuring which new one is a concept, a technology, a product or a service.

The repository pattern is one of the most misunderstood patterns in software design and engineering. Although Martin Fowler was clear about what it is and what it's for, the developer community interpreted it as something simpler than what it really is.

It is my pleasure to share my Graph Library in C#. Well... at least parts of it.

The Graph needs to be smart and self-validating. Likewise, it should be lightweight. The finishing touches give the Graph its proper constructor and a method that ultimately ends my quest.

When I started this quest, I found out that the graph in graph theory is complicated. However, focusing on the graph's definition made it look so simple in C#. After working on the Vertex and the Edge classes, I realized that I would need to expand my Graph class to something smarter.

The Edge is a monster of a beast!

Graph is a class with two main properties: a list of Vertex objects and a list of Edge objects. Vertex is a class with two main properties: an ID and a Value. Edge is a beast. Creating a class of type Edge is an exercise of self-control and avoiding temptations. As redundant as it may sound, the Edge can literally take you to the edge.

The Vertex is a class that has properties ID and Value. Both ID and Value must be set. This posed a problem because, in the real world, not everything has an ID. It should be possible to create a Vertex with both ID and Value available. However, it should also be possible to create a Vertex with just the Value, the Vertex internally assigning it a virtual ID.

Let's start with the Vertex. Wikipedia defines a vertex as the fundamental unit of a graph. If you read through the article, it expanded on how the vertex is used in a graph instead of actually describing what a vertex is and what, by itself, a vertex represents. I needed a definition that's less wordy and more specifically focused on the vertex itself. In some other illustrations, the vertex is described as a junction or a region. Again, these are vague. It seemed like the vertex cannot be defined without separating how a graph can be visualized.

Focusing on the basic definition of the graph guided my quest to a good path. G = (V, E) means that, a graph is a collection of vertices and edges. As we all can see now, there are three objects involved here: the graph G itself, the vertices V and the edges E. But what are vertices? And what are edges? In the same way that I wanted my graph to be true to the definition, I needed my vertices and edges to implement the "official" definitions as well.

In my quest to create my own graph theory library in C#, I started out to be conventional to being radical. I searched the Internet how programmers were doing it and got overwhelmed by the varied approaches. So I started reading about graph theory and got just as drowned with TMI (too much information). Finally, I realized that my problem would be easier to solve if I just focused on the first page of my research: the definition of the graph.

Many developers agree that the best way to express the world in code is through object-oriented programming, or OOP. OOP basically represents everything as objects. In fact, modern OOP languages have the "object" as the base or root class of everything, including the traditionally primitive types like char, integer, float, double and Boolean. From the most basic to the most complicated, they are all just objects in OOP.