Business Logic of an Application - My Experience as Newbie Programmer

If you read my other blog posts, especially the first ones, I explain there that my background is 15 years of corporate controlling (management accounting). And 2019 was for me a transition year to - writing accounting/business software. I accumulated some SQL/C# skills in the past years, and using my business knowledge and logic, I try to build some real tools from my previous workplace's accounting department.

I can state at the beginning that having an accounting/controlling background is very useful to understand the logic of my apps. Their goal is to automatize the work of accountants, to reduce to minimum the need of using Excel files and many emails for data collection, approval etc. So, my business background proves to be helpful!

Afterwards, comes the design and programming part.


First I design the database, using an abstract model of the data that can be used in the app.

Understanding table structures and relationships in excel, and the workflow, I can build the SQL tables and relationships, keys,  indexes, queries and reports that can be integrated to the application. I do this without having a formal training on how to build business applications, just following simple logic, then some database theory, SQL knowledge, normalization, etc.

Then I design the code and start writing it.

The models of the app are representing these SQL tables and relationships, and are the foundation of the application. Example: Business Units, Employees, Expenses etc.

Then comes the application layer, with MVVM -  a viewmodel that takes care of data coming from and going to the database, manipulating user inputs, checking, validating, iterating, etc...

Then there is the View of the application - WPF - for Windows interface, which is quite simple, user screens with tabs, tables (gridview), inputs, and reports, exports, imports of data. I try to make the user interface simple and easy to navigate, with a minimal risk to do stupid things. The users are happy, because they can use a centralized database app, and thus we can eliminate a lots of emails and excel files, which are very prone to error.

As I progress with my application, I go back sometimes to redesign the database (add fields, indexes, tables), and also the code of MVVM above. This is an iterative process for me, like continuous improvement.

Last step is to populate with data, and check. This is the most time consuming part, and can feedback to  database design and coding.

What do you think? Would you do something differently? Please feel free to give me feedback on the above topics.

Programming Is The Easy Part

I was wondering lately what is the real challenge in my current project, and what is the easy part. Do I manage the challenges the right way? Can I find some optimizations?

My answer to the challenge question is yes, there is a challenge. Understanding really well customer requirements is. What is the business process behind? What are the entities and properties?
What tables to I have as an input? Fields set as a flag? Certain situations require different treatment?
How much freedom has the user, to manipulate or corrupt data?

Yes, processing the real data that goes in the application is the real challenge, mapping it to entities that can survive the changes of the life of the application.

And what to do when the input data has some flaws? Data duplication, bad codification, violation of uniqueness... how to bridge this in my database?

Writing code is the easy part.

1. there is some routinely written code: SQL queries  - 80% are repetitive, following the same pattern (not exactly same commands). Writing the entity classes and the ORM functions that map DB procedures to entities, almost totally a routine.
2. Some semi- routinely written code - linking the WPF layout with bindings to entities, setup the ViewModel and View, draw basic XAML (copy-paste, than change)... Oh how I hate this XAML.

3. The interesting part is to write some algorithmic functionality: saving files and creating emails, generating views with filtered data, writing some more complex LINQ queries, generating invoices, creating Outlook Emails, Reports with Reportviewer...

What is then the hard part?

I think understanding the requirements really well and mentally mapping out a process how to tackle the solution step by step. Visually, View by View, Tabs, Tables, Reports, and a general succession.

Then comes the execution, test, populate with data, correction, again test, again addition of data, etc.

And finally the customer feedback, and again, corrections, optimization, refactoring, test, submission to the customer.

And after several attempts, there is the prototype that can be used at least on the short term, before the next iteration.

That's my approach. What do you think, what's your process?

My first big project (.NET) - and technologies used.

In the summer of 2017, together with my former finance manager, I began to design an internal recharge system for the company.
The choice was WPF for Windows (https://docs.microsoft.com/en-us/dotnet/framework/wpf/getting-started/walkthrough-my-first-wpf-desktop-application) using the old .NET, and an MS SQL Database.

We began to learn, exercise and think about the tools to use:
Our inspiration was: https://www.iamtimcorey.com/
1. IDE: Visual Studio Community 2017
2. WPF - for the visual part, front-end
3. ORM - Dapper - I think this is the best discovery ever! Tim speaks about this in his Videos.
https://www.iamtimcorey.com/blog/137806/entity-framework 

Please, check out his videos, about SQL, C# and lots of serious tutorials and courses.
 (https://stackexchange.github.io/Dapper/)
See also: https://dapper-tutorial.net/
4. MS SQL - I needed to review my SQL knowledge. Did a lot of exercises, and build many stored procedures for the application - dapper maps the entities to the data returned by those stored procedures, and I also used SP to insert and update entity data. Even if this was very time consuming in the beginning, proves to be very efficient and goal oriented.
5. lots of company data about expenses and the algorithm to create allocation keys - business logic designed together with Finance Manager.

The journey was hard. It took me probably 1 year to really get some speed, and show something to my Finance Manager colleague.

Luckily, I had my finance background, to understand the process we tried to automate, as there was a working excel macro/formula model as well used before the application.

But, I needed to fix my knowledge of C# (also using MVVM the first time for WPF) and SQL/Dapper. This meant weekly 2-3 hours of coding for 1 year to get some traction.
Main source for C# was google and Tim Corey, and my big discoveries were:

• lists/collections of items 
• LINQ and the foreach 
• breaking down the tasks to smaller chunks and functions
• writing a services class to export lists to excel using OpenXML
• first steps in async/await

A special challenge was how to integrate the good old WinForm control ReportViewer into WPF and MVVM. I will detail these maybe in another blog post.