Entity Framework Core

General Entity FrameWorkCore

dotnet ef migrations add 'MigrationName'

adds a new migration

if do this with blank one it creates a blank migration (good for seeding)

dotnet ef database update

after a succesful migration add it applies changes to database

dotnet ef database update MigrationName

to downgrade database

use 0 for the name if no prior migrations

Many-To-Many

Needs a "join-table"

each column is a foreign key into its respective table

Start with a fresh database

Change database name in connection string in appsettings.json

dotnet ef update database

defaults to last migration in your project (can-put a prior migration-name to downgrade

dotnet ef database update 0 (take last migration out)

remove command only works to migrations not-applied to the database

dotnet ef database drop

instances of class to be stored as database table...

public DbSetclass TableName {get; set;}

Constraints

with strings...EFC automatically makes them-as nvarchar(max), null (strings in c# are required)

1) Make changes to your Model (add a class)

Adjust DbSet under Data or Persistence

Public DbSetclass TableName {get; set;}

dotnet ef migrations add MigrationName (code has to compile successfully)

dotnet ef database update

if the above worked...

dotnet ef migrations add MigrationName (with no changes to model)

...creates blank migration

make changes to the "protected override void Up()

...can just copy prior one...change for new table/s and comment out prior what you added in

...be sure to change protected override Down()

......actually didn't delete any of the pre-existing data?

dotnet ef database udpate

Deleting from an already seeded data...

Execute teh SQL commands in protected override Up()

...Don't put anything in proected override Down

......migrationBuilder.Sql("DELETE FROM tableName");

what's needed in appsettings.json

Microsoft.EntityFrameworkCore.SqlServer

Microsoft.EntityFrameworkCore.Tools

Entity Framework Core setup steps:

• make your DbContext class(can copy the ApplicationDbContext one). In Data folder
• Setup your DbSets (each one in general is a table)
• add services.AddDbContext (in startup.cs)
• in fileExplorer (shell or cmd)
• dotnet ef migrations add "name of migration" --context "dbContext"
• dotnet ef database update
• dotnet ef migrations remove --context "NameOfContext"
• dotnet ef migrations list --context "NameOfContext"

Build APIs with Entity Framework Core

1) Build Domain Model

open terminal (make folder @ root)

2) dotnet add package (name)

dotnet restore (each time)

dotnet ef (see EntityFrameworkCore commands

dotnet ef migrations --help

3) Create DbContexes

register-it as a service for Dependancy-Injection

(want to use Dependencies so later can Unit-Test them using fake projects (startup.cs) (appsettings.json)

4) CODE-FIRST MIGRATIONS

dotnet ef migrations add InitialModel

dotnet ef database update

Entity Framework Core Commands

Code First Migrations to Populate Reference-Data

1) create blank "Seed Migration"

2) inside seedDatabase.cs

migrationBuilder.Sql(); in UP (always should update DOWN)

migrationBuilder.Sql("DELETE FROM Makes); (always should update DOWN if updated UP)

3) dotnet ef database update

Many to Many Relationships in E.F.C.

need a mapping class (manually add it)

needs a composite primary key (DbContext)

What is Prototype-Based Inheritance?

There are several different styles of Object-Oriented Programming, and the one JavaScript uses is Prototype-Based Inheritance. The system allows for repeated behaviour via the use of existing objects that serve as “prototypes”.

Even if the idea of prototypes is new to you, you will have encountered the prototype system by using in-built methods. For example, functions used to manipulate arrays such as map , reduce , splice and so on are all methods of the Array.prototype object. In fact, every instance of an array (defined using square brackets [], or — more unusually — using new Array()) inherits from Array.prototype , which is why methods like map , reduce and spliceare available by default.

The same is true of virtually every other built-in object, such as strings and booleans: only a few, such as Infinity , NaN , null and undefined have no properties or methods. At the end of the prototype chain we find Object.prototype , and almost every object in JavaScript is an instance of Object.prototype : Array.prototype and String.prototype , for example, both inherit properties and methods from Object.prototype . To add properties and methods to an object using prototype syntax, you can simply initiate the object as a function, and use the prototype keyword to add properties and methods:

Should I Override or Extend the Behaviour of Prototypes?

It’s possible to change the behaviour of built-in prototypes in exactly the same way that we can create and extend our own prototypes, but most developers (and most companies) would advise against this. If you want several objects to share the same behaviour, you can always create a custom object (or define your own ‘class’ or ‘subclass’) that inherits from a built-in prototype without making any changes to the prototype itself. If you’re going to be working with other developers, they’ll have certain expectations about JavaScript’s default behaviour, and editing this default behaviour can easily lead to errors. It’s worth noting, however, that not everyone shares this strong opposition to extending built-in prototypes. See, for example, this article from Brendan Eich, the creator of JavaScript. In this article (from 2005), Eich suggested that the prototype system in fact was built — in part — to make extensions possible!

Classes: create tight coupling or hierarchies/taxonomies

Prototypes: instances inherit directly from other objects. Instances are typically instantiated via factory functions or `Object.create()`. Instances may be composed from many different objects, allowing for easy selective inheritance.

In JavaScript, prototypal inheritance is simpler & more flexible than class inheritance.

When is prototypal inheritance an appropriate choice?

• Delegation (i.e. the prototype chain)
• Concatenative (i.e. mixins, 'Object.assign()'
• Functional (not to be confused with functional programming. A function used to create a closure for private state/encapsulation).
• all of them useful in their ability to enable composition, which creates has-a or uses-a or can-do relationships as opposed to the is-a relationship created with class inheritance.

A monolithic architecture means that your app is written as one cohesive unit of code whose components are designed to work together, sharing the same memory space and resources.

A microservice architecture means that your app is made up of lots of smaller, independent applications capable of running in their own memory space and scaling independently from each other across potentially many separate machines.

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.