Writing code is a mind and time-consuming process, a short story to prove

 Two days ago, while I’m trying to test a Customer module that I had codded, testing some data insertion from my code, I found out my insertion code on exception does not roll-back the insertion, I use to make this kind of transaction handling  at the DBMS on the sorted procedures, but I decided to make this from my code this time, so I searched that, and on C# .net you can use what called TransactionScope, which I implemented successfully, I wasted another hour on reading about the other types of transactions that available on .net framework, implicit and explicit, on one method or through the whole methods and across threads, “I hated threads!” I said, “Let's check about it … no! let’s get focused”.

 So I continued my tests and based on some new requirements that I just remembered to do, I have to add forging a key relationship between the Customer table and Company table, that each customer MUST be linked to a company that s/he worked at, this is a simple change, right? The easy way to continue my tests is by adding a new company record on the database and pass that CompanyId when creating the Customer from my code, but who’s wont to do it the easy way? And I decided to add the company module itself! with the APIs and the web, user interface to be ready to add the companies from there!

Therefore, I moved from focusing only on testing and checking the customer module features and operations to create another whole module!

 So I started to write the new code, and while I creating the DTOs (DataTransfer Objects

I noticed that some of the properties on the company entity is already on other entities, and since I love to make my code DRY as much as possible, I decided to put all the common properties at one class named EntityBase, and Make the other classes inherit from it, what makes me search through all my Entities to see the ones with the common properties, and found that there are entities that have a common proprieties but not the same as the one at EntityBase, so what to call the new Base entity? and after 25 mins of thinking and social media scrolling, I figure out all of those classes are having a common thing, they are all Configuration entities that save some configuration data on the database, So I created EntityConfigBase class. “But does EntityConfigBase seems to be a good name?” asking myself… I Changed it to ConfigEntityBase, “but it actually is a base of something, not something of the base, it's like superman not man super!” so I change it to BaseConfigEntity, “is to BaseConfigEntity or BaseEntityConfig?”, changed again, and to make everything looks standardized, I changed EntityBase to BaseEntity.

“What I was working on again? Oh, yes, Company Module”, So I continued to write the DTOs, and I noticed that I will need to add a Base DTO for Requests and responses to do the same abstraction that made by BaseEntity.

 Done that.

 Then, Adding module Business logic methods, “Create one by one or create a bulk? If I added a bulk creation that means I must add Upload an excel sheet, do I have to return the “not created” records to the end-user to be re-uploaded later? Create a DTO for that?” I moved on by adding Create method and CreateBulk method but with NotImplemented Exception and commented the code //TODO: write the Bulk create logic.

And I noticed that The company requires a code, an auto-generated code that must be unique and easy for the human eye to read and remember, “how to do that? Sequence? In which format? Do I need to link it somehow with the date of creation? Is it better to add letters on the code, or numbers only”, and the wondered mind continues non-stop, then I thought it will be great if wrote about all of this, starting from testing simple customer record insertion, to a lot of code written for another module.

Comments

  1. I just wanted to comment on one part, basicaly threading is better for efficiency, even if you hate it but it's the best of two evils, threading or performance bottle necks, any way great article, keep going

    ReplyDelete
    Replies
    1. Yes that's totally true, but it's one of the things I found my self doing but not fully understand 😂, but yes, it's better than bottle necks
      Thanks and I will.

      Delete

Post a Comment

Popular posts from this blog

How to Automatically deploy Configuration Files with Azure DevOps CD pipelines

Adding Multiple DB Contexts in your DotNet Project

Adapting a New Technology: A General Guide to keep Your Systems up-to-date