AJAX
Please see my other Web articles. This page demonstrates some of my AJAX skills in delivering server-side functionality to the client. AJAX Dropdown Update Table
Telerik: Dropdown with Template
Please see my other Telerik articles. Displaying dropdown choices with special formatting In this article I’ll demonstrate how to create a Telerik dropdown using templates to display data in a tabular format. First, I’ll create a ViewModel to serve as the data layer. Note: Ensure you’ve decorated the CustomerID property with the [Key] attribute or…
Telerik UI for ASP.NET MVC
Please see my other Web articles. This page demonstrates some of Telerik’s impressive suite of rich controls designed to empower users, increase productivity and streamline business processes. Telerik UI for ASP.NET MVC Display Dynamic Instructions Dropdown Filter on Multiple Columns Dropdown with Custom Date Format Dropdown with Template Grid-Dropdown Column Filter Grid-Display Success/Failure Notification Grid-Dropdown…
Design Patterns: S.O.L.I.D. Dependency Inversion Principle
Avoiding Dependencies Between Layers As part of the S.O.L.I.D. design principles, the Dependency Inversion Principle (DIP) provides guidance for ensuring layers within the application avoid unnecessary dependencies from coupling. DIP ensures each layer’s modules remain independent of one another and should depend on abstractions instead of concrete details, increasing usability and flexibility to change. In…
Design Patterns: S.O.L.I.D. Interface Segregation Principle
Providing Focused Behaviors for Classes As part of the S.O.L.I.D. design principles, the Interface Segregation Principle (ISP) supports other S.O.L.I.D. principles in providing classes with focused behavior by ensuring interfaces inherited by classes remain lean and focused on specific behaviors. To illustrate ISP, I’ll use examples from the Single Responsibility Principle (SRP) article. I’ll begin…
Design Patterns: S.O.L.I.D. Liskov Substitution Principle
Keeping Class Behavior Focused As part of the S.O.L.I.D. design principles, the Liskov Substitution Principle (LSP) ensures when designing classes, the user interface must operate by contact by ensuring during run-time, each object should be replaceable by objects instantiated by a subtype of that class or vice versa. For example, subtype classes (derived) must not…
Design Patterns: S.O.L.I.D. Open–Closed Principle
Supporting Change Without Breaking Software As part of the S.O.L.I.D. design principles, the Open–Closed Principle (OCP) ensures parts of software (classes) are open for extension, but closed for modification. In other words, you should be able to modify a class’ behavior without modifying its code. New methods are added by adding new classes without changing…
Design Patterns: S.O.L.I.D. Single Responsibility Principle
Limiting Class Scope As part of the S.O.L.I.D. design principles, the Single Responsibility Principle (SRP) ensures each class should only have one responsibility. This principle proactively ensures classes begin with a narrow focus, preventing future changes from affecting other parts of the application. In my previous article OOP: Class Design, I illustrated how a class…
Design Patterns: S.O.L.I.D. Overview
Please see my other Design Pattern articles. Ensuring software remains understandable, flexible, and maintainable In response to common design difficulties inherit within many software systems, a series of design patterns were integrated together to form the acronym, S.O.L.I.D., which representing a specific principle. In addition to producing programming code and architecture which is understandable, flexible,…
OOP: Class Design – Step 3 – Encapsulation
Please see my other Object-Oriented Programming (OOP) articles. Leveraging Encapsulation to Protecting Data & Behavior Implementation With my class requirements defined in my Class Design – Step 1 – Requirements article, I’m now ready to define the details of my Employee class. As demonstrated in my Inheritance article, I designed an Employee class which serves…
TechMbaBi 