►
From YouTube: Entity Framework Community Standup - Oct 14th 2020 - Cosmos DB: Repository Pattern .NET Wrapper SDK
Description
In this episode, fellow .NET TV host David Pine will join Jeremy Likness to discuss his Cosmos DB Repository pattern .NET SDK. The SDK aims to simplify the Cosmos DB .NET SDK by abstracting away some of the complexities, exposing an elegant API surface area, and providing C.R.U.D. operations through the IRepository interface.
As always, the EF Core team will be available to answer questions live.
Community Links: https://www.theurlist.com/efcorestandup-2020-10-14
Featuring: Jeremy Likness (@JeremyLikness) David Pine (@davidpine7)
#azure #cosmosdb #nosql
A
And
we
are
live
and
rocking
and
rolling
welcome
to
another
edition
of
the
entity
framework
core
teams
community
stand
up
today
we
are
taking
a
voyage
into
planetary
scale:
databases,
that's
what
the
materials
say
anyway,
with
azure
cosmos
db,
but
first,
let's
introduce
who's
on
the
the
show.
Today
my
name
is
jeremy
likness,
I'm
a
pm
for
net
data
at
microsoft
and
with
us
we
have
our
guest
david
pine
david.
Tell
us
a
little
bit
about
yourself.
B
So
you
have
your
own
show
too:
don't
you
yeah
yeah,
so
I'm
actually
one
of
the
co-hosts
for
the.net
docs
show,
and
hopefully
we
can
look
at
a
little
bit
of
that
source
code
later
and
kind
of
show
off
the
site,
we're
actually
using
the
repository
package
that
I
built
out
on
the
site.
So
it's
in
production
today,
nice.
C
D
Yeah,
I'm
shirojansky
the
first
and
only
iteration
on
twitter
and
probably
everywhere
else
with
my
name.
I
am
an
engineer
on
the
team.
I
do
a
lot
of
work
on
postgres,
I'm
very
interested
in
performance
and
hoping
we're
gonna
do
a
lot
of
that
in
6.0
and
generally
open
source
and
the
lower
level
data
api.
So
radio
on
that
system,
data
stuff
as
well.
That's
about
it!
D
A
Well,
let's
jump
into
some
community
links
and
then
I
know
david
has
a
lot
of
code
and
exciting
bits
to
share
with
us.
So
let
me
pull
up
some
links
here
and
the
first
link
is
a
little
bit
of
inception.
It's
a
show
note
that
links
to
a
show
note,
but
we
had
julie
lerman
was
on
the.net
doc
show
recently-
and
this
was
a
great
episode
and
I'm
not
saying
that
just
because
she
says
nice
things
about
our
team.
There
was
a
lot
of
good
content
and
information.
A
A
A
So
we
addressed
some
defects,
but
we
are
looking
for
everyone
to
pull
this
down
start
using
it.
We
want
to
catch
anything
critical
or
important
before
we
go,
live
pretty
soon.
Actually
in
the
next
couple
months,
I
guess
is
what
the
goal
is
for
that
do:
a
shy
or
bryce
any
thoughts
or
comments
on
release.
Candidate
2.
C
D
Nice
also,
this
is
as
close
as
it
gets
to
live,
so
I
really
really
encourage
that
any
everybody
and
anybody
just
try
it
out.
There's
we're
not
doing
really
anything
from
now
until
the
actual
go
live,
except
if
article
bugs
crop
up.
This
is
your
last
chance
and
I
really
hope
a
lot
of
people
go,
and
you
know
play
around
with
this
and
report
anything
that
happens.
It's
really
very
stable
by
now.
A
A
Our
next
link
is
I'm
not
gonna,
spend
too
much
time
on
it
because
it
segues
right
into
what
the
whole
intent
of
this
episode
is,
and
this
is
the
azure
cosmos
db,
repository.net
sdk
v
1.0.4.
So
this
is
a
blog
release.
You
can
go
out
and
read
about
what
we're
going
to
talk
about
today.
We
also
have
some
other
links
that
go
to
the
the
github
repo
and
some
other
resources,
but
without
jumping
into
it
or
stealing,
is
thunder
david.
Why
don't
you
tell
us
about
this
project
that
you
have.
B
B
B
A
Wonder
how
many
projects
that
are
official
now
started
out
unofficial,
not
that
that's
a
goal,
but
it
is
interesting
that
some
of
the
best
projects,
in
my
mind,
are
the
ones
that
solve
a
real
world
problem.
It's
not
someone
looking
to
hey
I've
got
a
solution.
Let
me
go
find
a
problem
right.
They're
like
I've,
got
a
problem.
I
need
to
fix
it
so.
A
B
Yeah,
so
this
is
really
just
an
abstraction
layer,
one
of
many
potential
abstraction
layers
when
you're
developing
things.
So
what
it
does
is
it
abstracts
away?
You
know
the
data
store
underneath
and
it
acts
as
an
interface
betwixt,
the
data
store
and
the
shape
of
the
objects
that
you
want
to
persist.
So
it's
a
very
simple
interface.
It's
I
repository
of
t
where
t
can
be
any
subclass
of
an
item
and
in
this
case,
there's
very
simple.
B
That's
a
good
question.
I
guess
it
could
be
applied
to
other
kind
of
providers
under
the
covers.
I
haven't
thought
of
that:
okay,
but
yeah
the
again.
It's
this
one's
married
to
cosmos,
db
right
now
and
it's
it's
tethered
to
the
net
sdk,
so
it
just
sits
on
top
of
that.
So
there
is
certainly
now
now
we're
talking
about
abstracting
away,
even
more
and
kind
of
making
it
even
more
generic
and
having
different.
I
know,
there's
ado
and
ef
and
all
those
other
different.
B
B
So
here
is
so
lots
of
people
like
to
talk
about
how
they've
done
the
repository
pattern,
and
you
know
I
just
created
the
the
unofficial
one-
that's
getting
some
attention,
but
it's
been
inspired
like
I
said
from
this
backstory,
and
this
is
we
were
talking
years
ago.
So
this
is
four
years
ago
where
I
was.
B
So,
if
we
jump
forward
to
the
actual
source
code
now
we
have
documentation
because
I'm
trying
to
be
I'm
trying
to
be
like
a
more
official,
you
know
open
source
developer
and
that
I'm
I'm
providing
some
contextual
bits
for
consumers
of
this
nuget
package
right.
So
you'll
get
all
of
the
documentation
for
the
apis
example
code:
how
to
do
it?
How
how
to
consume
it?
B
B
You
know
you
can
have
logical,
partitions
and
physical
partitions
and
you
have
a
relationship
of
a
database
and
then
the
database
underneath
that
has
containers
and
then
containers
can
have
different
partitions
right.
So
it's
just
a
it's
a
way
to
kind
of
scale
out
how
you
persist.
Things
and
consumers
of
you
know
cosmos
like
having
that
kind
of
finite
control,
so
we've
exposed
that
for
them
and
but
we
handle
a
lot
of
the
you
know
nuances.
B
So
if
you
don't
care
about
partitioning-
and
this
is
where
you
know
this
kind
of
comes
into
play-
where
using
this
simplified
repository
pattern,
it's
really
just
another
tool
in
your
developer
tool
kit
right,
it's
not
a
replacement.
Let
me
be
very
clear
and
state
that
again,
this
is
not
a
replacement
for
the
cosmos,
db.net
sdk,
it's
simply
another
tool,
so
you
can
use
either
or
I
don't
think
I'd
recommend
using
both
of
them
in
conjunction,
but
it
serves
a
different
purpose
right.
B
It's
really
for
more
simple
scenarios
where
you
as
a
developer,
need
to
persist
some
sort
of
thing,
and
maybe
you
don't
know
what
that
thing
fully
looks
like
yet
right,
so
it
can
be
schema-less
and
it's
just
to
use
cosmos
under
the
cover
to
persist
and
retrieve
those
as
needed,
and
you
can
have
you
know
full
object,
graphs
you
can
have
hierarchies.
You
can
have
any
of
those
things
that
you'd
really
like
and
they
just
have
to
be
some
classes
of
item.
B
So
partitioning
is
handled
for
you,
but
you
can
override
it.
You
can
actually
say
you
know.
The
default
partitioning
is
based
on
the
id,
but
you
can
override
that
by
having
a
subclass
that
overrides
the
get
partition
key
value
and
then
you
can
specify
like
if
you
want
to
have
a
synthetic
partition
key
instead
and
then
we've
got
the
type
parameter.
This
is
because
we
have
options
for
how
our
repository
persists
or
pocos
or
objects.
B
One
of
the
options
is
actually
to
by
default.
It
does
I'm
going
to
jump
around
a
little
bit
here,
but
one
of
the
options
is
to
have
a
container
per
item
type,
so
by
default.
This
is
false,
so
a
lot
of
people
in
the
cosmos
community
said
well.
I
like
having
my
data,
set
up
this
way
where,
if
I
have
a
an
object
of
foo,
I
want
to
be
in
a
foo
container
right
and
if
I
have
a
bar,
I
want
that
to
be
in
a
bar
container
and
the
way
I
initially
implemented.
B
This
is,
I
said,
I
don't
care,
you
can
have
multiple
items
that
are
different
shapes
and
it
just
works,
because
the
id
is
really
what
it's
pulling
back
from
and
it's
partitioned
that
way-
and
you
know
you
have
finite
control
over
that,
so
there's
various
options
for
how
you
want
to
utilize
this.
So
one
of
the
options
is
to
have
a
container
per
type
and
then
the
type
name
becomes
the
container.
A
C
B
B
A
So
there
was
a
question
here
I
want
to
show
really
quickly.
It
was,
can
this
be
used
with
atlas
mongodb
and
I'm
going
to
go
out
and
say
that
the
your
kit
sits
on
top
of
the
azure
cosmos
tv.
So
no,
but
the
repository
pattern,
of
course,
can
be
implemented
in
front
of
virtually
any
type
of
data
access
right.
B
Absolutely
yeah,
you
are
100
correct,
and
the
repository
pattern
is
something
that's
been
around
for
years
and
years.
It's
nothing
new,
it's
kind
of
new
to
the
cosmos
space.
Other
people
have
implemented
it,
as
I
mentioned
before.
I've
been
doing
it
for
a
long
time
now
that
pattern
can
be
re-implemented
in
other
types
of
scenarios,
but
this
one
is
married
to
cosmos
db
exclusively.
B
The
great
thing
is
it's
open
source.
So
if
you
would
like
to
take
a
stab
at
right,
going
out
there
and
doing
a
pull
request
and
kind
of
dissecting
those
parts
and
decoupling
them
a
little
bit
and
having
some
sort
of
provider
abstraction
layer
where
you
specify
you
know
we
want
to
use
here
and
get
that
same
interface
with
the
same
kind
of
simplicity.
I
would
highly
encourage
you
to
do
so.
A
Yeah,
I
was
just
going
to
say
too
one
thing
I
think.
A
lot
of
people
talk
about
with
the
repository
pattern
is
is
some
of
its
uses,
like?
Is
it
overkill
within
any
framework
right?
Because
then
any
framework
is
an
api
for
data
access,
and
one
of
the
things
that
I
found
is
I've
been
doing
a
lot
of
work
with
blazer
and
in
blazer.
A
If
you
are
trying
to
build
code
that
can
run
on
blazer
web
assembly
and
blazer
server,
then
the
repository
pattern
is
perfect
for
that,
because
you
can't
run
directly
to
entity
framework
core
from
inside
the
browser.
But
if
you
implement
the
repository
pattern,
what
you
can
do
is
talk
to
the
repository
pattern
on
the
server
you
just
talk
directly
to
the
database
in
the
browser
you
talk
to
a
web
api
that
calls
the
server
that
talks
to
the
database,
but
the
main
code
and
library
stay
the
same.
You
just
swap
out
that
implementation.
A
B
Yeah
I
started
writing
down
an
issue
to
track
a
new
feature
where
I
want
to
introduce
some
utilitarian
implementations
for
tests
so
that
consumers
of
this
could
have
like
a
test
implementation
that
they
could
rely
on,
for
you
know
doing
unit
tests
to
validate
like
if
they
have
a
service
tier
that
takes
on
the
the
repository.
What
does
that
look
like?
How
could
they
mock
things
out,
but
we
do
have
another
question
here.
B
Someone
or
not
a
question
someone's
mentioning
that
cosmos
db
is
costly
and
I'd
like
to
directly
address
that
by
saying
I
don't
have
to
pay
for
it.
No,
we
do
have
some
options
in
here
to
kind
of
look
at
that,
so
the
cosmos
team
has
been
doing
various
things
and
one
of
them
specifically
is
to
optimize
bandwidth.
I
default
this
to
true
and
what
that
does.
Is
it
actually
enables
content
response
on
write?
B
The
writing
of
the
response,
and
so
what
this
does
is
you
know
for
creations
or
upserts
patches
replaces
all
of
those
things
it's
going
to
reduce
the
networking
and
cpu
cpu
load
when
you
know
sending
things
over
the
network,
and
I
think
that
actually
helps
out
with
request
units.
I
think
that's
how
a
lot
of
it's
kind
of
you
know
our
user
kind
of
how
things
are
tracked
internally
for
cosmos
consumption.
B
In
addition
to
that,
we
allow
for
bulk
execution.
This
is
another
feature
that
marries
to
one
of
their
options
internally,
so
when
we
fan
out
so
what
I
mean
by
that
is,
we
have
an
interface
here
for
the
I
repository
that
says,
create
let
me
get
to
create
async,
given
an
innumerable
of
items.
So
all
these
values
under
the
covers
is
doing
a
task.when
all
and
it's
fanning
out
and
delegating
back
to
create
async
on
the
individual
thing
internally.
The
cosmos
client
has
a
way
to
kind
of
batch.
B
Those
calls,
if
you
explicitly
set
this,
allow
bulk
execution,
so
it
makes
it
a
little
bit
more
optimized
instead
of
having,
for
example,
a
list
of
50
items
that
does
50
api
calls.
It'll
do
one
api
call
with
50
items
right.
So
there's
some
little
things
like
that.
That
kind
of
help
address
some
of
those
costly
concerns,
because
again,
a
lot
of
this
is
tied
back
to
consumption
and
ru,
which
is
like
request
units.
A
Yeah
I
keep
creating
work
for
myself.
I
have
a
repo
that
I
haven't
updated
in
a
couple
years,
but
when
cosmos
first
came
out,
I
did
a
repo
that
pulls
down
the
usda
nutrition
database
and
stores
it
in
a
container
and
allows
you
to
work
with
that.
I'd
be
interested
to
implement
this
in
front
of
it
and
use
batching
and
see
how,
because
the
longest
part
is
when
it's
importing
all
the
items
and
and
wiring
up
the
database.
B
B
So
under
the
covers,
we
have
a
cosmos,
client
provider,
and
this
I'm
just
going
to
kind
of
go
through
the
interfaces
and
then
show
you
the
default
implementations
for
those
providers.
So
what
this
does?
Is
it
abstracts
away
the
consumption
of
the
cosmos
client
so
that
I
can
share
the
functionality
because
it
is
a
shared
cosmos,
client
for
the
sdk?
So
when
you're
consuming
my
sdk,
I'm
guaranteeing
that
you're
going
to
get
a
singleton,
so
it's
a
single
instance
of
that
client.
So
that's
one
of
the
recommendations
from
the
team.
B
In
addition
to
that,
we've
got
a
cosmos
container
provider
and
this
provides
the
container
for
a
given
item
again.
This
relates
back
to
the
ability
to
have
a
single
container
per
item
type,
but
if
you're,
if
you
have
that
toggled
off
you'll
just
get
the
same
container
right,
it
just
will
share
the
container
and
then
a
container
is
tied
to
a
database.
So
there's
a
database
that
sits
on
top
of
that.
B
You
can
obviously
override
that.
But
again,
the
only
thing
you
need
is
that
and
if,
if
you
don't
override
database,
you'll
get
a
database
instance
under
your
connection,
string
for
cosmos,
your
your
cosmos
resource
and,
if
you're
doing
a
container
per
type
or
actually,
if
you're
doing
a
not
container
per
type,
the
default
container
id
is
container
again,
that's
overrideable
and
then
you're
off
to
the
races
with
it.
B
So
then
you'll
get
your
container
instance
either
one
or
many
depending
on
how
you
configure
it,
and
then
we
actually
have
a
cosmos
partition,
key
path
provider,
and
this
basically
allows
for
the
finite
control
of
individual
items
to
specify
their
partition
key
path
and
again,
there's
defaults
for
you,
so
that
if
you
don't
want
to
have
that,
if
you
you
know
kind
of
opt
out
of
it,
there's
all
these
defaults
that
take
place.
So
you
could
use
this
with
literally
just
a
connection
string
and
it
will
work
for
persisting
all
of
your
subclasses
of
item.
B
A
So
I
love
that
I
hate
apis
that
require
you
to
configure
50
things
that
are
the
same
every
time
so
having
sensible
defaults
makes
sense,
but
before
we
we
jump
into
it.
I
don't
want
to
break
up
your
flow
because
you
may
be
getting
ready
to
talk
about
this
sure,
but
we
had
this
great
question,
maybe
a
second
on
task
versus
value
task.
I
know,
relatively
speaking,
value
tasks
are
newer
to
some
people
with
c
sharp.
So
can
you
explain
the
difference
and
why
you
would
use
one
over
the
other.
B
So
some
place,
I
have
a
task
versus
value
task
and
it's
intentional.
So
the
repository
exposes
all
value
tasks
and
the
reason
for
that
is
value
task
was
introduced
as
a
means
to
it's,
a
read-only
struct
so
being
a
value
type,
there's
less
concerns
with
potential
overhead
that
might
be
unnecessary,
unnecessary
allocations
at
certain
points
where
hot
paths
are
executed
or
something's.
Already
there
or
or
you
know,
there's-
and
I
guess
you
know
bryce
or
chime
in
to
help
out
with
you-
know,
examples
of
engineering.
B
A
B
Here:
here's
an
example,
so
the
container
provider,
so
this
one
is
a
task
intentionally
and
the
reason
this
is
a
task
is
because
I
know
that
within
my
implementation
this
will
be
awaited
multiple
times
and
there
was
a
blog
post
from
stephen
tobe
where
he
said
not
to
await
value
task
multiple
times.
So
that's
I
just
listened
to
him.
So
if
you
listen
to
shai,
I
I
listen
to
steven
so
yeah
this.
B
This
has
potentially
bit
more
overhead
because
it's
a
class
versus
a
value
type,
but
you
know
just
one
of
those
optimizational
things
where
my
general
rule
of
thumb
is.
If
I
can
get
away
with
using
a
value
task-
and
I
know
that
it's
not
going
to
be
awaited
multiple
times,
I
try
to
use
value
task.
That's
just
like.
I
guess
my
my
go-to.
D
I'll,
just
maybe
add
one
thing
so
yeah
this
is
a
subject.
That's
very
close
to
my
heart.
One
piece
of
guidance
here
is
that
when
there's
no
return
value,
so
when
you're
returning
like
a
non-generic
value
task
or
task,
then
the
general
guidance
is
that
you
want
to
return
a
task
rather
than
a
value
task,
because
there's
no
real
advantage
to
the
value
task
anymore.
It's
not
like
it's
horrible
to
return
a
non-generic
value
task.
It's
fine!
D
D
B
D
B
D
D
B
Otherwise
that
was
something
I
already
had
their
their
v4
of
their
sdk
actually
exposes
iasync
numerable,
and
I
have
already
have
a
branch
locally
that
I
haven't
pushed
up.
Yet
that's
been
kind
of
slightly
massaging
the
existing
api
to
see
where
maybe
v3
will
get,
because
one
thing
that
we
mentioned
is
that
blog
post
from
last
week,
you
know
that's
where
I
introduced
version
1.0.4
as
of
today,
I'm
already
on
2.0.2,
so.
B
B
But
we've
got
these
three
dependencies
that
we're
taking
on
and
we're
actually
expressing
this
constructor
with
an
expression
body
member
and
we
have
a
tuple
literal
here
that
is
going
to
be
deconstructed
and
assigned
to
our
read-only
fields.
So,
basically,
in
a
single
line
you
can
have,
what
might
otherwise
would
have
been.
You
know
five
or
six
lines
worth
of
code,
and
it's
just
a
way
to
express
that.
And
since
it's
internal
to
me,
I
kind
of
know
how
it's
going
to
work
and
I
don't
need
to
get
you
know
more
verbose.
B
A
A
D
B
We're
using
some
of
that
on
the
website,
so
hopefully
I've
got
time
to
share
some
of
that.
But
so
this
is
just
the
the
default
implementation
so
to
kind
of
walk
through
one
of
the
essential
user
flows
for
getting
so
there's.
Given
an
id
and
a
partition
key
internally,
we
rely
on
a
container,
so
we
walk
up
to
the
container
and
if
the
partition
key
is
default,
we'll
instantiate
it
given
our
default
scenario,
which
is
the
id
that
we're
looking
for
and
then
this
is
the
actual
container.
So
this
is
kind
of
the.
B
This
is
where
we
get
into
the
api
that
we're
encapsulating
and
abstracting
away.
So
they
have
a
read
item
async,
given
our
item,
our
partition
key
and
id
configure
weight
false,
and
then
we
get
this
item
response
of
t
and
then
I
hold
on
to
t
and
if
we
have
trace
or
if
we
have
debug
logging
enabled
we'll
you
know
serialize
that
lazily
for
consumers
so
that
they
can
see
what
the
objects
are.
B
Configurable
weight
false
basically
will
configure
the
synchronization
context
so
when
you
say
false
you're,
actually
specifying
that
you
don't
need
to
continue
on
the
captured
context,
and
one
of
the
ironies
of
this
is
that
there's
actually
not
a
synchronization
context
with
net
core.
As
I
understand
it,
I
thought
maybe
asp.net
core.
There
wasn't
one
specifically,
but
since
this
is
a
library
we're
going
to
be
kind
to
other
net
standard
2.0
consumers
that
might
be
on
different
run
times.
D
Is
that
yeah
asp.net
doesn't
have
they
dropped
their
synchronization
context
like
a
super
long
time
ago,
but
stuff
like
winforms
and
wpf?
So,
basically,
you
know
thick
ui.
If
that
term
is
still
used
so
ui
kind
of
stuff,
you
still
have
to
run
code
in
the
ui
thread
in
order
to
manipulate
stuff
and
that's
exactly
where
the
synchronization
context
gets
into
yeah.
So
basically,
every
library
on
earth
and
net,
which
should
be
agnostic
of
where
it's
running,
should
always
have
configure
weight
false
everywhere.
That's
kind
of
the
guidance
yep.
B
So
this
is
me
trying
to
be
a
good,
friendly,
opensource.net
developer
and
again,
I'm
just
a
content
developer
on
the
dot
net
team,
so
so
yeah.
So
that's
I
mean
basically
a
lot
of
things
are
just
kind
of
wrapping
away.
What
otherwise
might
be
something
like
this
right?
Some
sort
of
you
know
I'd
hate
for
consumers
to
have
to
write
this
every
time
they
need
to
get.
You
know
something
based
on
a
predicate
right
or
an
expression,
so
instead
I
abstract
it
all
away.
B
So
it's
really
really
simple
and
we
have
some
capabilities
within
here
that
are,
you
know,
pretty
exciting,
to
talk
about
so
there's
a
this
notion
of
like
a
feed
iterator
as
a
consumer
of
cosmos.
Do
you
really
want
to
know
about
a
feed
iterator?
Do
you
care
like
if
you
have
a
connection
string?
Wouldn't
it
be
great?
If
you
just
said
here's
my
item:
let's
go
get
it.
You
know
give
me
all
of
them
that
match
this
predicate
or
here's.
This
item
go,
save
it
right.
B
So
this
is
again
kind
of
speaking
to
the
advantages
of
what
the
goal
of
this
project
really
is,
and
it's
just
trying
to
abstract
away
all
of
these
various
complexities
where
you
have
to
have
a
database
and
you
have
to
have
a
container
and
you
have
to
have
various
items
with
partition,
keys
and
all
this
stuff,
and
it's
like
some
of
those
things
have
been
kind
of
it's
like
a
leaked
abstraction.
So
to
speak,
and
it's
I
think
the
repository
pattern
is
one
of
the
perfect
examples
to
apply
it
to
this
type
of
scenario.
A
Very
valid
because
when
I
talk
to
people
about
using
ef
core
provider
for
cosmos
db
a
lot
of
times,
one
of
the
reasons
they
use,
it
is
just
less
ceremonial
ritual.
It's
just
a
familiar
set
of
gestures
to
get
up
and
running.
Instead
of
doing
all
these
configuration
steps
that
you
set
so
having
something
like
this
with
sensible
defaults
again
is
definitely
a
boon
for
development.
B
Yeah
yeah,
so
we
actually
had
I'm
gonna
wait
for
my
internet
to
load
this.
There
was.
This
is
the
actual
repository.
So
I
evangelist
that's
my
github
and
azure
cosmos.net
repository
well.
There
was
an
issue
that
a
user
and
community
member
had
posted
and
they
were
asking
the
question
about
ef
core
db
provider
versus
this
right
and
they're
like
well.
Why
would
I
use
one
versus
the
other
and
I'm
like
well?
First
of
all,
this
is
unofficial,
so
you
know
it's
just
a
side
project
of
mine.
B
Take
it
as
you
will
do
what
you
want
with
it.
But
there
is
one
quote
that
I'd
like
to
call
attention
to,
and
this
is
I'm
not
going
to
share
the
individual's
name,
but
they
had
messaged
me
and
said
that
this
repository
library
is
smaller,
faster
and
simpler
than
the
ef
provider
by
a
wide
margin
for
for
the
cosmos
db
stuff,
and
it's
like
well,
if
I
could
help
someone
that
way.
But
again,
I
want
to
stress
that
this
is
just
another
tool
right
and
you
as
a
developer.
B
It's
your
responsibility
to
determine
what
tool
you
want
to
use
for
your
specific
job
or
your
specific
needs.
So
to
have
a
statement
like
this.
Is
you
know
it's?
While
it's
awesome
and
it's
flattering,
there
is
probably
a
lot
more
of
the
underlying
functionality.
That's
exposed
in
the
ef
core
provider
that
sits
on
top
of
cosmos.
That
probably
has
all
of
the
features
that
you'd
want
from
cosmos
right,
so
mine's
a
limited
scope
of
those
things
just
to
be
very,
very
clear.
D
D
D
I
know
bryce
does
too
so
I
I
think
it's
it's
a
great
compliment
by
the
way
so
like
in
ef,
for
example,
there's
there's
there's
a
whole
concept
of
change
tracking,
so
you're
going
to
be
loading
things
and
then
changing
them
in
your
program
and
then
ef
core
will
figure
out
exactly
what
needs
to
be
saved
back
right.
So
this
kind
of
very
high
level
functionality
is
something
that
you
know
dapper
and
this
kind
of
thing
just
they
don't
really
strive
to
do,
which
is
completely
fine
right,
you're
gonna
decide
as
a
user.
B
C
Decide
and
choose
we're.
Gonna
say
these
are
all
the
exact
reasons
I
love
dappers
like
I
don't
need
all
the
change
tracking.
I
don't
need
all
the
ceremony.
I
know
the
sequel,
I'm
gonna
write.
I
don't
even
need
a
link
provider,
but
on
the
other
hand
I
don't
want
to
deal
with
db,
parameter
objects
and
maybe
commands
and
getting
back
a
reader.
I
just
want
a
little
sugar
method
like
execute.
B
Before
joining
microsoft,
in
my
role
as
an
evangelist,
I
had
worked
with
some
enterprise
companies
doing
consulting
and
we
had
used
insight.database,
which
I
understand
it
to
be
an
early
early
fork
of
dapper
and
they
had
introduced
async
apis
to
it
before
stack
overflow
realized
that
they
needed
those
and
insight
database
was
very
much
that
same
type
of
thing.
It
was
simplified
ceremony,
so
when
we
this
that's
kind
of
like
the
evolution
of
where
I
decided
to
introduce
the
repository
pattern
on
top
of
cosmos.
D
B
We
we
said:
okay,
we
want
to
start
doing.
You
know
we
want
to
use
this
new
kind
of
document
database
thing
the
nosql
stuff
right.
We
were
so
tied
to
relational
data
structures
that
we
were.
We
thought
it
was
the
only
way.
So
it's
like
oh
we've
learned
about
nosql,
let's,
let's
abstract
away
some
of
these
complexities
and
have
this
and
that's
where
I
started
kind
of
doing
this
pattern.
So
I'm
gonna
share
my
screen.
B
B
So
one
of
the
common
scenarios
is
utilizing
the
repository
pattern
in
your
day-to-day
development.
So
imagine
that
we
have
this
web
tier.
So
in
the
samples
repo
folder
of
the
repository,
we
actually
have
like
a
service
here
how
to
do
that
from
like
a
background
service
or
something
or
a
web
tier
right.
B
Very
you
know
both
very
valid
use
cases
where
you
might
want
to
persist
and
read
data,
so
I'm
going
to
show
you
how
this
is
exposed,
so
both
of
these
projects
take
on
a
dependency
for
the
cosmos
repository
package
and
in
our
configure
services.
Again.
This
is
very
common
nomenclature,
with
net
core
kind
of
evolving,
from
like
startup
semantics,
with
owen
and
katana
things
like
that.
But
it's
been
you
know
a
first-class
citizen
now
for
a
while,
and
that
is
dependency
injection.
B
So
we
have
this
eye
service
collection
services
and
from
that
we
have
an
ad
cosmos
repository
that
takes
a
configuration,
an
eye
configuration.
So
these
are
two
very
common
things
that
exist:
a
configuration
in
a
startup
and
this
adding
of
the
thing
that
you
care
about
and
an
extension
method
that
just
comes
in
to
the
microsoft.extensions.dependency
injection
namespace.
B
So
what
that
does?
Is
that
wires?
Up
from
my
configuration,
the
consumption
of
icosmos
repository,
that's
literally
the
only
line
that
we
need,
in
addition
to
actually
having
the
configuration
provided
from
one
of
the
providers.
I
simply
have
it
in
properties
right
now,
as
a
startup
arg,
so
I'll
show
what
that
looks
like,
but
you
could
have
it
in
environment
variables.
You
could
have
an
app
settings
json,
you
can
have
it
wherever
things
might
want
to
be
like
app
secrets
or
azure
key
vault
things
like
that.
B
So
now
we
have
a
model,
I'm
going
to
show
you
my
model
and
I've
say
class
language,
and
we
are
a
subclass
of
item
and
we
add
just
our
get
sets
the
things
that
we
care
about
right,
very,
very
straightforward,
nothing
complexing
there
at
all.
We
have
a
programming
style,
you
know
functional
object,
oriented
procedural
and
I
just
threw
this
together.
So
there's
going
to
be
people
that
are
going
to
say,
wait
a
second
there's
more
programming
styles
that
aren't
there
and
don't
focus
on
that
focus
on
how
we've
modeled
this
right.
B
So
then
we
have
a
language
controller,
and
this
is
just
an
api
controller
and
we
are
a
subclass
of
controller
base
and
from
here
for
the
convenience
of
you
know,
I
could
take
on
like
an
irepository
of
language
here.
If
I
wanted
instead
di
will
provide
either
that,
like
an
irrepository
of
language
or
I
added
for
convenience-
and
I
repository
factory-
so
I
can
say
factory.repository
of
language,
and
now
I
get
an
eye
repository
of
language,
and
I
have
this
api
that
does
get
post
put
and
delete.
B
So
this
this
entire
controller,
this
entire
api
surface
area,
which
is
42
lines
of
code
and
our
startup,
which
is
a
single
line
after
we
ported
our
thing
in.
If
we
set
this
as
the
default
startup
and
one
other
thing
I
want
to
call
attention
to,
I
do
have
swagger
swagger,
you
know
swashbuckle,
which
is
the
open
api
stuff.
Since
I'm
using
that,
I
don't
have
to
write
a
user
interface
right.
I'm
trying
to
keep
it
very
simple.
B
So
I'm
gonna
run
this
application,
and
I'm
gonna
show
you
that
this
is
actually
talking
to
an
actual
cosmos
instance
and
will
work
the
way
you'd
want
it
to.
But
I
guess
I'm
curious
for
those
who
are
watching
how
how
difficult
does
that
look
from
a
consumer
aspect
to
take
on
the
dependency
to
the
project?
Say:
here's
my
configuration,
add
it
into
your
di
pipeline
and
then
simply
ask
for
eye
repositories
of
the
thing
you
care
about.
B
Yes,
oh
no,
that's
that's
a
very
common
thing.
I
do
that
after
every
show.
Don't
worry
I
think
someone
had
mentioned.
They
wanted
to
do
a
like
some
sort
of
little
abstraction
like
something
that
like
masks,
any
private
keys
or
things
that
are
shown
like
there's
some
sort
of
tooling
option
there
for
streamers.
So
if
you're
out
there
and
you're
thinking,
oh,
how
could
we
do
that?
I
think
someone
actually
had
done
that
at
one
point
in
time,
but
it
was
tethered
to
like
the
azure
portal.
A
Yeah
the
cloud
advocates
team
had
a
tool
that
they
created
that
automatically
understood
which
tags
were
like
subscription,
ids
and
keys
and
would
blur
them
out
on
it.
But
the
portal
team
changed
the
portal
faster
than
the
blurry
team
could
keep
up
with
the
glory.
So
I'm
not
sure
if
that's
still
maintained
or
kept
up
now
anymore.
So
we
just
recreate
the
resources
now.
B
I
had
release
because
I'm
I
was
actually
inspired
by
you
jeremy.
I
just
saw
one
of
your
repositories
that
you
had
put
out
there
on
github
and
you
have
all
of
the
ci
cd
stuff
in
place
to
do
like
publishing
your
nuget
packages,
and
I
need
help
with
that.
So
all
I
have
is
like
build
validation.
That's
why
I
was
on
release
mistakenly.
So
when
I
started
to
try
to
debug
just
now,
it's
like
you
can't.
Are
you
sure
you
want
to
debug
this
release,
build
because
that's
what
I'm
doing
with
my
packages?
B
A
B
A
A
big
fan,
there's
a
tool
called
nerd
bean,
get
version
and
that's
a
a
package,
there's
basically
a
command
line
tool
that
you
can
install
as
a
global.net
tool,
and
you
can
include
it
in
your
directory
props
or
your
your
solution
files
and
it
automatically
handles
versioning.
You
just
tag
it
it'll
tag
the
commits
it'll
stamp,
the
builds.
A
B
B
B
So
yeah
now
we
get
back
this
array
of
languages
right,
so
we've
got
c
sharp
and
javascript.
Apparently
the
only
two
languages
that
we've
persisted
in
here,
but
you
get
an
id
you
get
aliases,
you
get
all
the
things
and
you
can
create
new
ones.
So
if
we
want
to
post
a
new
language,
let's
do
so.
I'm
gonna
get
rid
of
id,
because
that
does
that
comes
automatically
and
we
could
say
what
do
we
want
to
say
type.
B
B
Go
faster
fancy
go
fast
playing
alias,
obviously
we're
going
to
have
an
alias
that
is
the
s
f,
g,
f
l,
which
is
just
the
acronym
description,
jeremy's
made
of
thing
and
we're
gonna
say
it's
functional
and
we're
gonna
execute
that
and
it's
gonna
execute
insert
thing
it's
in
there
already
back
instantaneously
almost-
and
I
I
think
yeah.
So
one
of
the
cool
things
is:
I've
got
the
debug
stuff
toggled
on
for
our
logging.
B
So
you
get
to
see
kind
of
like
the
request
and
the
response
you
get
to
actually
see
the
generated.
Cosmos
db,
query
definitions
themselves,
which
is
really
cool.
You
actually
get
to
see
the
hydrated
json
objects
put
to
the
output.
That's
an
option
right
if
you
want
to
have
debug
on
so
it's
really
convenient
for
kind
of
analyzing
how
things
are
working.
B
A
B
Right
yeah,
so
that's
it's
pretty
much
that,
in
a
nutshell,
we're
actually
using
it.
One
thing
I
didn't
show
was
we're
actually
using
it
on
the
dock
show
itself,
so
the
net
dock
show-
and
this
is
a
bit
of
a
little
segue
into
what
our
our
things
about
so
the.net
doc
show-
is
a
blazer
server-side
web
app
that
I
built
and
we
use
it
to
kind
of
host
historical
shows
and
upcoming
shows-
and
this
is
where
people
can
submit
ideas.
B
But
all
of
these
shows
these
are
basically
little
show
objects
that
are
pulled
directly
out
of
the
cosmos
db
and
I'm
using
this
repository
I
have
a
service
layer
that
wraps
it
and
and
we've
got
yeah
all
the
show
information
we've
got
upcoming
shows.
If
I
click
on
it,
I
did
click
on
it.
Right
click,
press
buttons,
oh,
I
must
have
clicked
on
an
actual
show,
but
anyways
yeah.
B
So
there's
the
source
code
for
that-
and
I
did
have
another
link
here-
that
we
can
probably
add
to
the
url
list,
which
is
a
discussion
more
formally
on
partitioning
in
azure
cosmos
db.
But
that's
yeah,
that's
pretty
much
it
in
a
nutshell:
there's
various
ways
to
consume
it.
It's
di
ready
configuration
options,
pattern,
ready,
async
value
task,
all
the
things
generic
enjoy.
A
B
Well,
yeah
I'll
show
you
here
so
we
have.
This
is
the.netdocs.web.
This
is
the
blazer
server
side
project
and
in
there
we
have
a
reference
to
our.netdocs
service
services,
and
that
service
is
just
again
all
these
different
services
for
the
app
itself.
So
we've
got
date
time
service.
We
have
an
eye
schedule
service,
we
have
logic,
apps
we're
using
for
some
of
the
scheduling
and
emailing
and
calendar
management.
B
We've
got
a
twitch
service
and
twitter
service.
You
know
to
pull
up
images
and
stuff
and
twitch
to
pull
down
video
content
and
post
video
content.
Things
like
that
right,
all
this
cool
stuff
and
then
we
have
an
ischedule
service
and
the
ischedule
service.
Just
works
against
this
doc's
show
object
and
the
doc
show
is
a
subclass
of
item
and
it
has
all
these
things
right.
It's
got
people
in
it.
It's
got
hosts
tags,
title
url,
various
bits
of
information
about
our
show.
B
We
even
have
hard-coded
people
that
are
hosts,
I
need
to
add,
I
need
to
add
cecil
and
maria
maria
wenzel
and
cecil
philip
both
have
joined
as
hosts.
So
let
me
just
do
that
right
now.
I
have
to
add
them,
but
yeah.
So
that's
our
ischedule
service
and
the
implementation
is
very,
very
simply
just
the
decorator
pattern
taking
on
an
irepository
of
doc
show
and
we
we
pull
all
of
it.
B
We
persist
all
of
it
and
we
actually
created
like
a
simple
content
management
system,
basically
for
our
site,
so
we
can,
from
there
create,
shows
edit
them
and
they're
live
instantaneously
on
the
site,
we're
using
background
services,
the
hosted
service
pattern
from
net
core
and
we're
using
memory.
Caching-
and
things
like
that.
B
So
if
we
go
look
at
the
service
worker,
we've
got
our
ischedule
service
and
our
immemory
cache
and
the
background
hosted
service
basically
will
sit
here
and
hydrate
our
cache
accordingly
and
the
site
is
very,
very
responsive,
but
we
can
bust
the
cache
internally,
since
we
can
walk
up
to
the
immemory
cache
and
as
things
update,
you
know,
it's
basically
pump
updates
into
that,
and
it's
all
real
time.
We
don't.
B
We
don't
even
have
like
a
staging
or
testing
site,
it's
just
all
in
production,
which
is
great,
but
the
really
cool
thing-
and
this
is
one
thing
I
really
want
to
emphasize-
is
if
you
are
watching
this,
show
one
of
the
huge
advantages
I
can't
stress
this
enough
is,
if
you
go
look
at
the
change
log,
all
the
commits
from
this
website
and
look
at
the
pocos,
the
classes
here
under
the
services
and
look
at
the
evolution
of
these
objects,
because
cosmos
is
schemeless
right,
it
doesn't
really
pertain.
It
doesn't
really
care
about
it.
B
Right
as
your
object
evolves.
You
can
add
things
where,
in
you
know,
historical
situations
of
relational
databases.
You
would
be
breaking
the
world
or
an
if
yeah,
for
example,
you'd
have
migrations,
raise
your
hand
if
you
love
doing
migrations
and
having
all
that
extra
stuff
right
come
on,
come
on,
and
that's
that's
just
one
of
those
things
it's
one
of
those
things
right.
So
for
me
it
was
something
I
was
personally
not
a
fan
of
and
with
cosmos.
D
A
A
D
A
It
just
it
makes
it
very
interesting
to
go
down
that
decision
tree
and
start
with.
I
I
mean
it
used
to
be
right.
The
traditional
c
sharp.net
developer
worked
on
sql
server,
so
it
was
like.
I
have
a
database.
I
go
sql
well
now,
there's
options
and
it's
that
path.
I
have
data.
What
am
I
going
to
do?
How
am
I
going
to
store
this?
What's
the
most
optimal
way
and
of
course,
cost
comes
into
it
api.
A
B
A
C
A
Well,
since
we're
talking
about
that,
I
worked
on
a
project
that
was
like
that.
Basically,
it
was
a
migration,
and
the
existing
project
had
two
sides
to
it.
It
had
a
a
business.
You
know
compute
side
that
was
basically
a
bunch
of
visual
basic
objects
and
it
followed
the
pattern
of
having
one
base
class
that
does
everything
in
the
world
and
then
everything
inherits
and
just
calls
into
it,
and
then
it
had
a
database
that,
as
a
customer
I
could
make
changes.
And
if
I
made
a
change,
it
would
split
off
a
table.
A
Prefix
with
my
customer
name
automatically
generate
the
schema
to
have
my
custom
field
then
generate
a
view
that
would
take
the
regular
field
joined
to
the
the
extended
table,
and
so
they
were
very
successful
company
and
had
hundreds
of
customers,
so
their
database
literally
had
hundreds
of
these
prefix
tables
that
were
customizations
and
extensions,
so
wow,
so
something
that
would
have
been
easily
solved
right
in
the
document
database
world.
So.
B
B
No,
so
what
you
can
well,
I
mean
so
this
is
where
the
type
comes
into
or
or
the
discriminator
rather
comes
into
play.
So
if
you
have
a
repository
of
b
and
that's
what
you
ask
for
from
d,
I
and
you
have
the
shape
of
that
object
as
declaratively
as
a
b
right
for
the
type
parameter
and,
for
example,
you're
using
it
and
you're.
You
have
object
a
and
you
try
to
deserialize
object
b
into
object,
a
it's
going
to
work
partially.
B
If
there's
things
that
are
named
the
same
right,
because
it's
just
json
serialization
and
there's
going
to
be
a
conflict.
So
I'm
actually
going
to
basically
fail
and
say
you
don't
even
get
that
object
back
because
the
the
discriminator
doesn't
match.
But
I
think
what
you're
actually
asking
is
a
slightly
different
question
where
you
have
one
repository
using
and
consuming
another
repository
and
that's
not
really
a
likely
scenario.
Either
so
what
I
did
want
to
show
is
the
availability
of
with
dependency
injection.
B
They
have
these
generic
type
parameters
that
you
can
say
of
t.
So
one
of
the
cool
things
is,
I
say,
add
singleton
and
I
say
type
of
I
repository
blank
type
parameters,
comma
maps
over
to
the
definitely
typed
default
repository,
and
what
this
does
is
since
they're
generic
types,
it's
a
one-to-one
mapping,
so
any
explicit
subclass.
B
If
you
have
foo
and
bar
they
get
their
own
default
repository
implementation
from
di,
and
the
same
is
true
with
the
repository
factory.
It
just
uses
the
service
provider
under
the
covers
to
serve
that
back
to
you,
but
I
do
have
an
example
of
where
this
is
useful
and
a
good
friend
of
mine,
brady
gaster,
is
using
my
library
right
now
and
he
has
a
an
ingredients,
recipe,
controller
api
and,
as
part
of
that,
he's
got
two
eye
repositories,
one
for
recipe
and
one
for
ingredients,
and
you
could
take
both
of
those.
B
So
you
could
have
multiple
parameters
into
your
con.
Your
controller
constructor,
where
you
take
on
an
eye
repository
of
recipe
and
an
eye
repository
of
ingredients
or
you
could
take
the
convenience-based
factory
approach
where
you
say
just
give
me
the
factory
and
internally
in
the
constructor.
I
will
resolve
a
repository
of
recipe
and
a
repository
of
ingredients.
A
All
right
well
that
takes
us
to
the
top
of
the
hour,
and
that
was
that
was
fun.
I'm
excited
about
cosmos
db.
I'm
excited
about
pulling
up
that
old
project
of
mine,
that
I
keep
getting
security
alerts
for
and
updating
it
to
to
patch
it
and
use
the
new
pattern.
So
thank
you
for
your
time,
david.
Thank
you,
everyone
for
tuning
in
to
the
show.
As
always,
we
appreciate
you
please
reach
out
to
our
team.