ASP.net

View Model, View Bag, View Data

model-binding (all stored as name-value pairs)

Form Values

Route Values

Query Strings

if model-binding fails, MVC doesn't throw an error (ModelState.IsInvalid)

ViewData

Un-typed Key-Value Dictionary

ViewData["cheese"] = CheeseData.GetAll()

ViewData["cheeses"] = cheeses (sets Data in ViewData on controller)

@ViewData["cheeses"] = to retrieve in View

These 2 are equivalent:

@model ListCheeseMVC.Models.Cheese....then use "Model" throughout cshtml

ViewBag

Dynamic-Object which is wrapper around the ViewData

ViewBag.CheeseData.GetALl()

ViewModel

Model class to be used in view

Allow our views to-be "strongly-typed". Good for Form-Validation

@* *@ are razor view comments

Tag Helper

label asp-for="Name" /label... generates a label for Name property of "ViewModel"

Error Messages in View

div asp-validation-summary = "All"

in ViewModel: [Required(ErrorMessage="")]

override page styles

@RenderSection("overrideStyles", false)

then in view... @Section overrideStyles {put style tags in here}

handling hidden inputs

input class="form-control" asp-for="classProperty" type="hidden"

good for preserving properties on an object back and forth through view

Interfaces

are used to specify methods and properties that a derived class will have access to.

Like a contract...if a class implements an interface...then the interface guarantees the class has access to that method.

Doesn't contain Code or Data

Big role in Abstraction and Styles

Used to specify related behaviors that may be common across unrelated classes

abstract classes

similar to interfaces BUT can't be instantiated. Frequently partially or never implemented

abstract classes cannot be instantiated

Can contain code or data

A class can inherit from only one abstract class (but can implement multiple interfaces)

Can specify methods as virtual to force a derived class to implement their own definition.

If you have classes that will have a lot of the same code/methods...go with abtract class instead of interfaces

Containing Class doesn't hold implementation (derived classes do that)

Derived classes must implement all derived methods.

Example: A Person abstract class that has a PrintName() method in addition to some data such as default value for an age.

should-be used to collect and specify behavior by related classes.

you IMPLEMENT an interface while you EXTEND an abstract class

Sealed Modifier prevents it from derived or overriding of methods

Sealed can only be applied to methods that are overriding "virtual" methods of the base class.

slightly faster because of run-time optimizations

static class

Used to create data or functions that don't need to be instantiated

only contain static members

inherently sealed

Can't be instantiated

Generics

allow you to enforce Type Safety by letting you tailor a method or class to a precise data-type

example: Array Class to store list of users or products and then when you use them you can use them as Users or Products (don't have to do any unboxing)

4 Pillars of O.O.P.

• Abstraction
• Polymorphism
• Inheritance
• Encapsulation

Abstraction

abstraction allows making relevant information visible

are usually implemented as Abstract classes or Interfaces

Polymorphism

...when classes have different functionality while sharing the same interface

Blue Ray Disc player(is the interface) able to play DVD(object) or CD(object)

Employee class...another class inherits from it(contractor)..then a permanent Employee class...SO they have different CalculateSalary classes (polymorphic)

Overloading with your methods is also a form of polymorphism

creating multiple methods in a class with same name but different parameters and types is called method overloading...is an example of compile time polymorhpism which is done at compile time.

Run Time polymorphism would be Method overriding

Encapsulation

Related features

Encapsulation prevents access to implementation details.

encapsulation ex: setting stuff as private inside classes

Inheritance

when an object or class is based on a parent class (taking on its characteristics)

What is .NET?

• managed execution environment to manage and build applications
• CLR + FCL (common language run time + framework class library)

CLR Common Language Run-Time...offers security, memory management, exception handling

FCL (framework class library) sits on top of the CLR

C# compilers create Managed code - garbage collecting, references etc...

Unmanaged code compiles straight to machine code...

...Not portable

...Not managed by the CLR

Boxing vs. Unboxing

Boxing is the process of converting a value type to the type object (integer into an object)

Boxed values use more memory and require memory lookups to access.

Unboxing extracts the value from the object

Dependency Injection

allows your class to no longer be responsible for instantiating its own dependencies

helps to develop loosely coupled code

3 ways - method, constructor,

Derives from the concept of Inversion of Control

Gang of Four

Authors of "Elements of Reusable Object-Oriented Software"

Repository Pattern

Allows applications to perform with CRUD type operations

Provides an obstraction of data so that

Unit of Work

Maintains in-memory updates

sends in-memory updates as one transaction to the database

often used with Repository Pattern...similar to how transactions in database are done which can be rolled back.

Monolithic Pros:

• The major advantage of the monolithic architecture is that most apps typically have a large number of cross-cutting concerns, such as logging, rate limiting, and security features such audit trails and DOS protection. When everything is running through the same app, it’s easy to hook up components to those cross-cutting concerns.
• There can also be performance advantages, since shared-memory access is faster than inter-process communication (IPC).

Monolithic Cons:

• Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability.
• Monolithic architectures are also much harder to understand, because there may be dependencies, side-effects, and magic which are not obvious when you’re looking at a particular service or controller.

Microservice Pros:

• Microservice architectures are typically better organized, since each microservice has a very specific job, and is not concerned with the jobs of other components.
• Decoupled services are also easier to recompose and reconfigure to serve the purposes of different apps (for example, serving both the web clients and public API).
• They can also have performance advantages depending on how they’re organized because it’s possible to isolate hot services and scale them independent of the rest of the app.

Microservice Cons:

• As you’re building a new microservice architecture, you’re likely to discover lots of cross-cutting concerns that you did not anticipate at design time. A monolithic app could establish shared magic helpers or middleware to handle such cross-cutting concerns without much effort.
• In a microservice architecture, you’ll either need to incur the overhead of separate modules for each cross-cutting concern, or encapsulate cross-cutting concerns in another service layer that all traffic gets routed through.
• Eventually, even monolthic architectures tend to route traffic through an outer service layer for cross-cutting concerns, but with a monolithic architecture, it’s possible to delay the cost of that work until the project is much more mature.
• Microservices are frequently deployed on their own virtual machines or containers, causing a proliferation of VM wrangling work. These tasks are frequently automated with container fleet management tools.

Positive attitudes toward microservices, despite the higher initial cost vs monolthic apps. Aware that microservices tend to perform and scale better in the long run.

Structure the app so that services are independent from each other at the code level, but easy to bundle together as a monolithic app in the beginning. Microservice overhead costs can be delayed until it becomes more practical to pay the price.