In my application I currently have a URL model class and a URLQuery class.
My URL class has a few properties and a save method that uses the injected database class to save the object and it's properties to the database.
My URLQuery class has a method for taking in some conditions and returning rows from the database and instantiating them as URL objects from the URL class.
Recently however, I have come to feel that maybe my code is mixing different design patterns. For example, the URL model class needs the database class injected into it and it feels messy to instantiate a URL class and setup it's dependencies inside another class that may be just to do with crawling the URL etc.
So this is when I look into using a factory class with a database dependency and injecting it into my other classes. It could have methods like:
Would this make sense? Does my URLQuery also make sense or am I miss-using another design pattern? I'm just confused, as I see in so many tutorials etc the usage of a save method directly in a model class etc.
I understand your dilemma. When we start learning design patterns, we start thinking they should/must always be used and forget about the problem we are trying to solve. Identifying design-pattern before identifying the problem, is a problem itself.
Your scenario is actually simple, and so keep the code simple too. KISS.
You need just one model/entity URL, one class to save/read from db and then a crawler that just needs URLs, nothing else.
public class URL {
// only properties
}
// You inject this repository whenever you want to work with db
public class URLRepository {
// This will talk to db
public URL Get(<param>) { } // fetch from db
public int Save(<param>) { } // save to db, and return it's ID
// .. and so on
}
public class Crawler {
// This is just concerned about URL objects
// nothing else
}