Building a generic repository for mongodb
hello folks I was thinking build a generic repository structure for mongodb. but someday if i want to change the db i don't want to start all over again. I hope I explained myself well.
51 Replies
I think the critical bit you missed was your actual question
I don't think so but the question is: I'm creating a api with using mongodb. I want to build a repo for being generic(i mean if i want to change db someday i don't want to code all over again). And that repo will communicate with mongorepo. but how do I build it i don't know really. I'm kinda new sorry.
(Normally questions can be identified by a question mark "?")
"How do I build it" is a pretty vague question, which means you're less likely to get a useful answer. Which bit of it are you struggling with exactly?
if you're not gonna help me pls stop bro. you know what I mean. I'm at the office right now as a intern. and i'm in a hurry. I explained my problem. What should I do?
here its your question mark
I'm trying to find out what exactly you need help with 🤷♂️ Cool, I'll stop. Good luck!
Thank you mr so clever
What have you tried and where are you stuck?
If you "dont know how to build it" then you have not done enough research
Also, fix your attititude. Entitlement is not a good look and will get you ignored or banned.
I've searched for new mongoDB entity framework core provider can't figured out for how to implement it. and also i tried to create a generic repo and implemented to mongodb repo. but couldn't run the server i guess i skipped some parts or did somethings wrong.
EF Core with mongo isnt a great fit
EF is primarily for relational databases - Mongo is a document database
how you model and query your data is entirely different
I explained my problem and look at his answer bro i didn't do anything to make him tilted
I'm fully with Canton here lol, you are the one with the problem, not him 🙂
what's your suggestion then, my senior didnt wanted to see mongodb library in my service codes.
🤣
See, thats where your repository comes in
the services talk to the repo, the repo talks to mongo
bam, no mongo related stuff in your services.
And ideally, your repository API surface doesnt expose any mongo internals
yes i thought the same. I could do it Java easily but im kinda new at .net
When using a document database, I strongly urge you to have repositories over your aggregate entities, not the individual component types as you might with a relational db
I did something like this. Probably there are so many mistakes but the logic?
what do you think
how to model your data is actually by far the hardest problem to solve with document databases
ObjectId is a mongo internal type
if your interface exposes it, you are leaking mongo internals to your service layer
repo owns the database connection - that will probably lead to some problems. How do you know when to dispose it?My senior wanted a basic api communicates with mongo from docker. But he told me that I want you to write a generic code for someday if we'll change our database we can do it by easily
I understand that.
sorry
Which is why I point out that you must not leak any mongo DB internals
wdym by leaking
Look at your interface
the input parameter type for
Delete is ObjectID
the full name for ObjectId is...
MongoDB.Bson.ObjectId
that type is from a mongodb packageoh got you now
i should change them
yep.
also, generic repositories are not very useful on their own, most of the time
They only provide the simplest of querying - get by pkey, get all, etc
then what are your suggestions
Combine it with typed interfaces
ie
the generic one gives you the generic methods, but IUserRepo can give you actually domain-related methods
like
FindUserByEmail etc
its rarely enough to only have the generic methodsoh I see. I saw few examples like that but I didn't understand the point for defining UserRepo as class and also as Interface
in Java I've never used it. Maybe it's wrong too but I'm not used to use it so that's why I didn't understand the point
well the entire purpose of having interfaces is to refer to the implementation via the interface
if you already know the concrete implementation, why bother haviing interfaces at all?
then
since you have a baseclass for generic repos, which is fine
not bothering it's just don't know how to use it so scared to understand nothing
Sure you can skip the interfaces and use the raw repo directly
Nothing stops you from doing
public class UserRepository : GenericRepository<User> and injecting UserRepositorywhat do you think which one more make sense. You are more experienced than me. I'll listen to you as suggestion and also mentor:=)
instead of make sense I can say useful or popular.
I mean, if you dont plan on having other implementations or use mock testing, its fine to not have interfaces
thats not a problem.
The main point I wanted to get across is that
GenericRepository<User> will rarely be useful as anything other than a base class
because specialized queries are needed for 99% of appsI don't plan right now but I might need it
VS and Rider both can "Extract interface" from a class, so that wont be a problem
so I should use it with other repos to make it useful right
yeah, use it as a base class
have you done any database modelling before?
so I'll use base class for implementing methods to other classes?
?
If you come from java, surely you know what a base class is? 😛
I didn't say I know Java🥲
I'd probably even consider marking the
GenericRepository<T> class as abstractI'll try it
you will need some contraints on it regardless
Read up on database modelling with aggregate entities and C# generic contraints
those topics will be important
definitely I'll
any other suggestions to look for
not at this time
and last question. Is it really good idea that having generic repo and also mongo repo?
I think question is little awkward but I hope you understand what I mean
Huh?
No I don't understand
Mongo repo?
I mean Mongo's methods for a class name I made up I d
didn't know how do I name it
I still dont follow
The entire idea behind repos is to hide the implementation
So you should not have a mongo repository, your repos represent your data - whatever that might be
my generic codes will communicate with any other db's but right no matter what I use
If
I can correctly build the structure