New pages

23:5123:51, 1 February 2025 Software Architecture vs Software Design (hist | edit) [4,426 bytes] Chr1ss (talk | contribs) (Created page with "= Software Architecture vs Software Design = The distinction between software design and software architecture is a classic point of debate, and definitions often vary depending on context, frameworks, or even individual experts. The confusion often stems from overlapping terminology and differing interpretations in the industry. 1. Software Architecture * What it is: The strategic layer of a system. It defines high-level structural decisions, system-wide patterns, and...")

06:2206:22, 22 January 2025 Repository (hist | edit) [12,064 bytes] Chr1ss (talk | contribs) (Created page with "= Repository Pattern = The Repository Pattern mediates between the domain and data mapping layers, using a collection-like interface for accessing domain objects. It provides an abstraction of data persistence, enabling applications to work with domain models without being concerned about database connections or queries. == Purpose == The primary purpose of the Repository Pattern is to achieve a clean separation and one-way dependency between the domain and data mappin...")

08:3708:37, 21 January 2025 Dockerizing .NET Applications (hist | edit) [7,043 bytes] Chr1ss (talk | contribs) (Created page with "= Dockerizing .NET Applications = == Docker == Docker is an open-source platform that automates the deployment, scaling, and management of applications in lightweight, portable containers. Containers encapsulate all the dependencies, libraries, and configurations needed to run an application, ensuring consistency across different environments. Docker is extremely popular, especially in DevOps and microservices environments. It is widely used for developing, shipping, a...")
07:5007:50, 21 January 2025 Optimal Work Enviornment (hist | edit) [5,139 bytes] Chr1ss (talk | contribs) (Created page with "= Optimal Work Environment = thumb == Intro == What makes a good work environment for a backend developer in my mind involves several key factors: == Management == * Clear Project Requirements: ** Begin with well-defined project requirements: *** Specification of the system's functionality *** Performance expectations *** Architectural guidelines * Well-Defined Tasks: ** Clearly define tasks or user stories. Developers must have a solid...")

13:2813:28, 20 January 2025 Syntax Highlighting (hist | edit) [6,518 bytes] Chr1ss (talk | contribs) (Created page with "= SyntaxHighlighting in MediaWiki = First, I attempted to install the extension specifically designed for this purpose: [https://www.mediawiki.org/wiki/Extension:SyntaxHighlight MediaWiki Extension:SyntaxHighlight] To check if all requirements were met, I used this PHP test script provided by ChatGPT: == Description of the Script == The script tests the server environment for compatibility with the SyntaxHighlight extension. It checks for PHP functions, Python insta...")
06:5406:54, 20 January 2025 Law of Demeter (hist | edit) [4,481 bytes] Chr1ss (talk | contribs) (Created page with "= Law of Demeter (Principle of Least Knowledge) = {{#mermaid: graph LR A["A"] -->|Friend| B["B"] B -->|Friend| C["C"] A -.-> C: "Messages from A to C are discouraged\n(*A friend of a friend is a stranger)" A -->|OK| B: "Messages from A to B" }} The Law of Demeter, also called the Principle of Least Knowledge, is a design guideline for developing software, particularly in object-oriented programming. It aims to reduce dependencies between components, enh...")

20:1120:11, 18 January 2025 Coupling and Cohesion (hist | edit) [5,147 bytes] Chr1ss (talk | contribs) (Created page with "= Principle of High Cohesion and Low Coupling = In software architecture, '''cohesion''' refers to the degree to which the elements within a module or component are related to one another. High cohesion implies that the elements within a module are strongly related and focused on a single, well-defined purpose. '''Coupling''' refers to the degree of interdependence between software modules or components. Low coupling means minimizing the dependencies between modules, e...")
20:0320:03, 18 January 2025 Structural (hist | edit) [4,158 bytes] Chr1ss (talk | contribs) (Created page with "Here is the improved and well-structured version of the article using MediaWiki syntax and a C# example, with explanations added: = Structured Programming = Structured programming stands as a pivotal advancement in software development, offering a more organized and systematic approach to writing code. It promotes the use of well-defined control structures to enhance code clarity, maintainability, and reliability. This paradigm emerged as a response to the challenges p...")
19:5819:58, 18 January 2025 Procedural (hist | edit) [3,952 bytes] Chr1ss (talk | contribs) (Created page with "= Procedural Programming = Procedural programming represents a significant advancement within the imperative paradigm, offering developers a structured approach to organizing and managing code. Programs are constructed around procedures or routines, which encapsulate a set of instructions to perform a specific task. Unlike the unstructured nature of early imperative programming (e.g., assembly language or early versions of BASIC), procedural programming introduces modul...")
19:5219:52, 18 January 2025 Logic (hist | edit) [4,912 bytes] Chr1ss (talk | contribs) (Created page with "= Logic Programming = Logic programming focuses on describing the desired result or outcome rather than specifying the step-by-step procedure for achieving it. In this paradigm, programmers define a set of facts and rules, and the program's interpreter or engine deduces solutions based on logical inference. For example, in procedural or object-oriented languages, developers typically specify a sequence of instructions to manipulate data or perform calculations. In cont...")
11:5811:58, 18 January 2025 Specification (hist | edit) [8,057 bytes] Chr1ss (talk | contribs) (Created page with "= Specification Pattern = == Overview == The '''Specification Pattern''' is a software design pattern used to encapsulate business rules, logic, or criteria into a reusable, combinable, and testable format. It provides a clear and modular way to evaluate whether objects meet certain conditions. This pattern is particularly useful in domains with complex validation or filtering requirements. == Key Concepts == * '''Encapsulation of Criteria''': Encapsulates rules or con...")
09:0009:00, 18 January 2025 Code Smells (hist | edit) [12,965 bytes] Chr1ss (talk | contribs) (Created page with "<syntaxhighlight lang="python"> def hello_world(): print("Hello, World!") </syntaxhighlight>")

18:0618:06, 17 January 2025 Working with XML (hist | edit) [7,076 bytes] Chr1ss (talk | contribs) (Created page with "# XML in CSharp __TOC__ In C# you can use the built-in System.Xml namespace to extract data from XML files and write XML files. There are two common approaches for working with XML in .NET: == Streaming approach (Using XmlReader and XmlWriter) == The streaming approach is more memory-efficient for large XML files, as it processes the XML sequentially without loading the entire document into memory. Here's an example: <pre> using System; using System.Xml; // Reading fro...")
17:5317:53, 17 January 2025 Exception Handling Best Practices (hist | edit) [4,252 bytes] Chr1ss (talk | contribs) (Created page with "= Exception Handling Best Practices MSDN = MSDN: [https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions Best practices for exceptions] __TOC__ Exception handling is a critical aspect of software development, ensuring that applications can gracefully handle errors and prevent crashes. In this article, we'll delve into best practices for handling and creating exceptions to enhance the robustness and reliability of your applications. =...")
17:4417:44, 17 January 2025 Startup of ASP.NET Core Web App (hist | edit) [5,667 bytes] Chr1ss (talk | contribs) (Created page with "= Startup of a Web Application = __TOC__ The startup process of an ASP.NET Core web application is a crucial phase where the application is initialized, configured, and prepared to handle incoming HTTP requests. center|alt=Screenshot of Counter Strile stating My Config Settings == Initialize, configure and execute == The `Program` class contains the Main method and this is the starting point of the application. The Startup proces...")
17:3417:34, 17 January 2025 Storing Database Connection Strings (hist | edit) [4,118 bytes] Chr1ss (talk | contribs) (Created page with "= Storing Database Connection Strings = __TOC__ Nearly all Application interact with a database at some point. Therefore a database connection string is needed, that typically includes details such as the server or host name, database name, authentication credentials (such as username and password), and other parameters necessary for establishing a connection to the database. Properly configuring the connection string is crucial to ensure that the application can access...")
17:1517:15, 17 January 2025 Using Statement for Resource Management (hist | edit) [5,025 bytes] Chr1ss (talk | contribs) (Created page with "= using Statement for Ressource Management = __TOC__ == Basic Example and Overview == <pre> using (var resource = new SomeResource()) { // Use the resource } </pre> This idiom ensures that resources like file streams or database connections are properly disposed of when they are no longer needed, even if an exception occurs. The `using` statement in C# is primarily used for resource management, especially for objects that implement the `IDisposable` interface. The...")
17:1117:11, 17 January 2025 Record Type (hist | edit) [4,047 bytes] Chr1ss (talk | contribs) (Created page with "= Record Types in C# = __TOC__ == Overview == Record types, introduced in C# 9.0, provide a way to declare '''immutable''' data types. They are ideal for representing simple data containers or DTOs (Data Transfer Objects) where immutability, value-based equality, and a sensible string representation are desired. == Purpose == The purpose of record types is to simplify the declaration of immutable data types and reduce boilerplate code associated with defining classes...")
17:0717:07, 17 January 2025 Null-Conditional-Operator (hist | edit) [4,878 bytes] Chr1ss (talk | contribs) (Created page with "= Null Conditional Operator (?.) = __TOC__ The Null Conditional Operator (?.) is a powerful feature introduced in C# 6.0 that provides a concise and safe way to access members or elements of an object without worrying about null reference exceptions. It simplifies null checking and enhances code readability. == Overview == The Null Conditional Operator (?.) allows you to safely access members of an object without explicitly checking for null. It short-circuits the eva...")
17:0117:01, 17 January 2025 Implicitly Typed Variables (hist | edit) [2,324 bytes] Chr1ss (talk | contribs) (Created page with "# Implicitly Typed Variables __TOC__ center|alt=Meme comparing variable decalaration in csharp and c, where it is wild. == Overview == Implicitly typed variables, introduced in C# 3.0 with the `var` keyword, allow declaration without explicitly specifying data types. The compiler infers variable types based on initialization expressions, promoting code readability and flexibility while maintaining strong typing. == Purpose == I...")
16:5316:53, 17 January 2025 Extension Methods (hist | edit) [2,945 bytes] Chr1ss (talk | contribs) (Created page with "= Extension Methods = __TOC__ Extension methods, introduced in C# 3.0, allow to add new methods to exiting types. == Purpose == The purpose of extension methods is to extend the functionality of types without modifying their source code. == Example == Consider the following extension method: <pre> public static class StringExtensions { public static string Reverse(this string input) { char[] chars = input.ToCharArray(); Array.Reverse(chars);...")
16:5016:50, 17 January 2025 Conditional Cases in Switch Statements (hist | edit) [774 bytes] Chr1ss (talk | contribs) (Created page with "When working with switch statements, you can use a when clause instead of an if/else in your case expressions. The switch statement with pattern matching was introduced in C# 7. <pre> switch( cow.Name ) { case "Alf": if( cow.Weight >= 100 ) { // Do This } else { // Do that } break; default: // Else break; } </pre> <pre> switch ( cow.Name ) { case "Alf" when cow....")
16:4716:47, 17 January 2025 Async Await (hist | edit) [5,856 bytes] Chr1ss (talk | contribs) (Created page with "# Async/Await __TOC__ center|none|alt=Meme Async await challenge accepted showing men synchron swimming and men fail at it == Overview == Async/Await is a feature introduced in C# 5.0 that simplifies asynchronous programming by allowing to write code in a more synchronous style. It enables non-blocking execution of code, particularly useful when performing I/O-bound operations or long-running tasks. == Threading and Tasking == Threa...")
16:3016:30, 17 January 2025 Pipeline (hist | edit) [6,031 bytes] Chr1ss (talk | contribs) (Created page with "# Pipeline Architecture __TOC__ Pipeline architecture is a software design approach that structures system components into interconnected stages or phases, each responsible for a specific task or operation. It facilitates the efficient processing of data or tasks through a series of sequential steps. == Overview == Pipeline architecture is inspired by the concept of assembly lines in manufacturing, where each step in the process adds value to the final product. Simila...")
16:2416:24, 17 January 2025 MVVM (hist | edit) [9,019 bytes] Chr1ss (talk | contribs) (Created page with "= MVVM Architecture (Model-View-ViewModel) = __TOC__ MVVM Architecture, short for Model-View-ViewModel is dominantly found in frontend development and used primarily in software development to separate concerns and enhance the modularity and testability of code. It facilitates a clear separation between the user interface (View) and the business logic (Model), with the ViewModel serving as an intermediary that handles the presentation logic. "This approach offers a way...")
16:1916:19, 17 January 2025 Hexagonal (hist | edit) [5,216 bytes] Chr1ss (talk | contribs) (Created page with "= Hexagonal Architecture (Ports and Adapters) = __TOC__ Hexagonal Architecture, also known as '''Ports and Adapters''' Architecture, is a design pattern that emphasizes separation of concerns and focuses on the interactions between the core business logic (hexagon) and external systems (ports and adapters). It enables flexibility, test-ability, and maintainability by decoupling the application's business logic from external dependencies. "This approach is an alternative...")
16:1316:13, 17 January 2025 Layered (hist | edit) [5,566 bytes] Chr1ss (talk | contribs) (Created page with "= Layered Architecture = __TOC__ Layered architecture is a software design approach that organizes system components into distinct, self-contained layers, each with a specific responsibility, promoting [separation of concerns](https://en.wikipedia.org/wiki/Separation_of_concerns) and maintainability. == Overview == This is a possible implementation with Domain-Driven Design (DDD) as "North Star", .NET, Entity Framework Core (EF Core) and a REST API 😅👍. A well-str...")
15:5315:53, 17 January 2025 Singleton (hist | edit) [6,903 bytes] Chr1ss (talk | contribs) (Created page with "= Singleton = Category:Patterns Category:Creational Design Patterns __TOC__ none|alt=Meme of Highlander 'There can be only one' The '''Singleton Pattern''' (Creational) ensures a class has '''only one''' instance and provides a global point of access to that instance. It is one of the simplest design patterns in terms of its class diagram; however, its implementation requires careful consideration to handle multithreaded scenario...")
15:4215:42, 17 January 2025 Prototype (hist | edit) [4,749 bytes] Chr1ss (talk | contribs) (Created page with "=Prototype= Category:Patterns Category:Creational Design Patterns __TOC__ left|alt=Prototype bender, the robot from the tv show futurama, showing lots of bender after he copied himself The '''Prototype pattern''' (Creational) allows you to create new objects by copying an existing object (prototype). This can be useful when you want to create new instances that are similar to existing ones without the overhead of initializing them fr...")
15:2315:23, 17 January 2025 Mediator (hist | edit) [9,924 bytes] Chr1ss (talk | contribs) (Created page with "= Mediator Pattern = Category:Patterns Category:Behavioral Design Patterns __TOC__ The '''Mediator Pattern''' (Behavioral) promotes loose coupling between objects by centralizing their interactions through a mediator object. center|alt=Mediator Plane "Everybody who had fish" == Benefits == * '''Decoupling''': Components can interact with each other through the mediator without needing direct references, reducing dependencies. * '...")
15:1415:14, 17 January 2025 Factory Method and Abstract Factory (hist | edit) [9,937 bytes] Chr1ss (talk | contribs) (Created page with "= Factory Method and Abstract Factory = Category:Patterns Category:Creational Design Patterns alt=Meme showing Morpheus "Waht if I told you you could create classes with functions" The Factory Method and Abstract Factory are creational design patterns used to create objects and provide a way to create objects without specifying the exact class of object that will be created, allowing for flexibility and extensibility. == Use Ca...")
14:4814:48, 17 January 2025 Decorator (hist | edit) [13,001 bytes] Chr1ss (talk | contribs) (Created page with "= Decorator Pattern = __TOC__ The '''Decorator pattern''' (Structural) allows behavior to be added to individual objects, either statically or dynamically, without affecting the behavior of other objects from the same class. == Benefits == * '''Flexibility''': Decorators provide a more flexible approach to extending an object's behavior compared to subclassing. * '''Non-intrusive''': Add new responsibilities to objects without changing their existing classes. * '''Scal...")
14:1314:13, 17 January 2025 Adapter (hist | edit) [9,840 bytes] Chr1ss (talk | contribs) (Created page with "= Adapter = __TOC__ The '''Adapter Pattern''' (Structural) allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code. The primary purpose of the Adapter Pattern is to achieve '''compatibility''' between different interfaces. It is particularly useful when integrating new features or systems with legacy code, as it allows communication between the new and old...")
13:5213:52, 17 January 2025 Anticipation of Change (hist | edit) [2,074 bytes] Chr1ss (talk | contribs) (Created page with "= Anticipation of Change Principle = __TOC__ == Introduction == The Anticipation of Change Principle underscores the importance of designing systems that can adapt to evolving requirements and environments. == Purpose == It advocates for developing software systems with adaptability in mind, recognizes that change is inevitable in software development, and aims to mitigate the impact of future changes by designing systems that are easy to modify, extend, and maintain....")
10:4310:43, 17 January 2025 Separation of Concerns (hist | edit) [3,481 bytes] Chr1ss (talk | contribs) (Created page with "= Principle of Separation of Concerns = __TOC__ == Introduction == Software engineering's main goal is to address the '''complexity''' inherent in designing, developing, and maintaining software systems. One foundational principle, the '''Principle of Separation of Concerns''', stands as a guiding beacon in this pursuit. === Purpose === The Principle of Separation of Concerns recognizes the limitations of human cognition when confronted with complex tasks. By isolating...")
10:2310:23, 17 January 2025 SOLID (hist | edit) [5,531 bytes] Chr1ss (talk | contribs) (Created page with "__TOC__ = SOLID = SOLID is an acronym representing a series of principles aimed at promoting more understandable, flexible, and maintainable software development. These principles are widely accepted in object-oriented programming and are essential for reducing complexity, avoiding code smells, and ensuring scalability. The SOLID principles: {{#mermaid: graph TD SRP-->|One reason to change| SOLID OCP-->|Open for extension, closed for modification| SOLID LSP...")
08:0908:09, 17 January 2025 Clean Code (hist | edit) [7,798 bytes] Chr1ss (talk | contribs) (Created page with "== KISS == '''Keep It Sweet & Simple''' - Simplicity is paramount. Methods should be concise, with one expression per line, and names should be meaningful. Classes should be focused and manageable in size to facilitate ease of change. The balance between readability and conciseness is essential. == DRY == '''Don't Repeat Yourself''' - Redundancy is a significant obstacle to clean code and system performance. Identifying and eliminating repetitive patterns is crucial for...")
07:4607:46, 17 January 2025 Domain Driven Design (hist | edit) [4,338 bytes] Chr1ss (talk | contribs) (Created page with "== Domain-Driven Design (DDD) == === Introduction === "Domain-Driven Design" is a highly influential book authored by Eric Evans, with a foreword by Martin Fowler. It offers a comprehensive framework for designing complex software systems that align closely with the problem domains they address. The book introduces essential principles and practices for creating elegant and maintainable solutions, emphasizing collaboration between domain experts and developers. It remai...")
07:3407:34, 17 January 2025 Imperative and Declarative (hist | edit) [3,084 bytes] Chr1ss (talk | contribs) (Created page with "== Implicit and Delclarative == Programming paradigms serve as guiding principles, delineating different styles of constructing software code. Among these paradigms, two stand out as foundational: '''imperative programming''' and '''declarative programming'''. === Imperative Programming === '''The Classic Paradigm''' Rooted in the earliest days of computing, imperative programming forms the basis of traditional programming languages like Pascal, C, and assembly langua...") originally created as "Implicit and Delclarative"
06:5406:54, 17 January 2025 Functional Programming (hist | edit) [8,237 bytes] Chr1ss (talk | contribs) (Created page with "== Functional Programming == Functional programming in C# can complement both imperative and object-oriented programming paradigms. Let's get started with functional programming in C#: === Delegates === C# provides delegates and events, which are critical for functional programming - these include `Action` and `Func`. === Action Delegate in C#: === The `Action` delegate is a predefined delegate type in C# that represents a method which performs an action and does not r...")

21:2621:26, 16 January 2025 OOP, DDD, AOP and EDP (hist | edit) [4,359 bytes] Chr1ss (talk | contribs) (Created page with " == Paradigms == Paradigms are high-level guidelines and the most abstract, followed by principles, patterns, idioms and code smells. There are also mixins, which always apply to one certain programming language. <mermaid> graph TD; subgraph Abstraction Level Paradigms[Paradigms] Principles[Principles] Patterns[Patterns] CodeSmells[Code Smells] Mixins[Mixins] end Paradigms --> Principles Principles --> Patterns Patterns --> CodeSmells C...") originally created as "Guides/Paradigms, Principles, Architectures and Patterns\Paradigms"
20:1420:14, 16 January 2025 Paradigms, Principles, Architectures and Patterns (hist | edit) [4,228 bytes] Chr1ss (talk | contribs) (Created page with "This is a collection of relevant Principles, Architectures and Patterns regarding our central ideas of development and code-bases.") originally created as "Guides/Paradigms, Principles, Architectures and Patterns"
20:0920:09, 16 January 2025 Guides (hist | edit) [371 bytes] Chr1ss (talk | contribs) (Created page with "Guides on coding in general, for working with ASP.NET, EF Core, etc.. but als stuff regarding DevOps and Project Management.")

1 February 2025

22 January 2025

21 January 2025

20 January 2025

18 January 2025

17 January 2025

16 January 2025