This is one of the most common test approaches. We implement our code based on unit tests. Each feature of your application should have a unit test designed before its implementation. The first time you run this test will fail. You finish your development when your test pass. We should follow the RGR development cycle.
More and more we want automatic things. The operating processes that are always the same can be done autonomously following a set of steps. In the not too distant past, every time we want to deploy an application we build and copy those generated files to the server. So we need to have remote access to a server machine, we need to know which files need to be copied, where we should put them, and which other multiple services must be restarted. I’m tired of just describing this process.
The CI/CD principle, which means Continuous Integration and Continuous Delivery or…
This is a behavioral pattern that allows defining multiple strategies to resolve a problem. You can change the strategy that will be applied. Imagine your GPS, you can choose between multiple types of routes to arrive at your destiny. The fastest, the beautiful, the most economic, etc. These are a few examples of strategies that were defined in your GPS. Accordingly to your choice, the system will generate the route. The following image shows a possible organization in your solution.
It’s very common to have complex objects in our solutions. Objects that have multiple fields and each field is difficult to build. Who is familiar with this type of object? Everyone, I guess. Sometimes we have gigantic constructors to create an object. Let’s see an example:
public class Order
{
public Buyer Buyer { get; set; }
public Seller Seller { get; set; }
public Product Product { get; set; }
public double Price { get; set; }
(...) public Order(Buyer buyer, Seller seller, Product product, double price, (...)) { Buyer = buyer; Seller = seller; Product = product…
One of the first things that you must define when starting a new solution, is the architecture that you will implement. Where the interfaces will be? Where your implementations should be made? Where you should place your HTML pages? These are some questions that are answered by the chosen architecture.
There are multiple options to use depending on your type of solution. Let’s imagine an example of a Web Application that reads and writes data from a database.
This is one of the most used architectures. It’s quite simple and distributes the responsibilities for 3 layers.
Nowadays these types of tools are increasingly more used because of the necessity to integrate multiple systems and applications. The cloud providers were also very important for the popularization of these types of tools. They have their own services to provide these books and hooks. The second ones are increasing their popularity due to the variety of applications and websites that provide support for them.
It is a simple tool to automate your current operations. A runbook is a set of predefined procedures that can be defined in a Powershell script.
Nowadays, the creation of APIs is a very common solution when we want to make some features of our system available for other components. Since that, we can put an API as a public component and allow you to use it. The thing is that if you want to make some requests in your backend you must create an HTTP client in order to do the necessary requests.
That’s the main question that you want to have the right answer. It helps you to ignore some operations when you are developing a service because it avoids you from reinventing the…
Left or right? You always have more than the visible options. Sometimes you need to convert some objects to another type. For instance, when you want to map a domain entity to its DTO (Data Transfer Object). Imagine that you have 30 domain entities and another 30 DTO entities, one for each domain entity. You will have a method for each type of entity to convert those objects to its DTO. This would be the first option that I would think.
It would be great, right? Yes. I present you the Implicit and Explicit operators for C#. Their objective is…
This is one of the most used and recommended patterns to apply in an application that works with any type of database. It provides a simple way to create a standard for your CRUD operations. If you like generics, you will love this pattern.
Because centralizes all the basic operations regarding an entity in one main class. Without this approach, we would have multiple classes with the same logic but for a different entity.
The following code block shows the main interface:
public interface IRepository<TEntity> { TEntity Find(params object[] keyValues); IEnumerable<TEntity> FindAll(); void Insert(TEntity entity); void Update(TEntity entity); void Delete(TEntity…
This pattern is focused on changes in objects. As Martin Fowler said, this unit keeps a list of changed objects in a transaction context. Also manages the write operation and deal with the concurrency problems. We can look at this as a context, session, or object which follows all the changes on data models during a transaction.
Just another programmer with some ideas.