Question

I have a few questions about “best practices” in my application structure. I make use of skinny models, and have service layers which do most (all) of the database interaction. The models call the service layer when they need a database transaction.

I also have a factory class which can return forms, models, and service layer classes. This factory class may also return a “search” class which acts as a very simple DBAL and is used by my service layer.

This search class has helper methods such as getAll() and getById().

I’m slightly confused about which parts of my application should have access to the search class; currently my model uses the static factory to build the search class when it needs to retrieve an entity by it’s ID. Should my models instead be calling my service layer to make this call, thus negating the need to use my factory class to return the searcher?

I guess I don’t like the idea that my database can potentially be accessed from multiple parts of my application, when really I’d rather everything need to go through my service layer first.

Tips and feedback are much appreciated!

Answer 1

I would end up creating a SearchService (which implements an interface i.e. ISearchService) class which the model, or any other code, that wants to access the Searcher would interact with.

This way you keep a clear separation from the Searcher class, or factory, which could change in the future. The other benefit is that, by having all the search related code in the SearchService, it becomes a lot easier for devs to understand the code, since they know that search related code is in the SearchService, rather then dotted around the codebase, calling factory methods, etc.

Also, by using an ISearchService, you allow yourself the option to use Dependency Injection, which is a nice way of having your object initialised for you, and not having to worry about implementation changes.

That’s just my preference though, rather then this being a right/wrong way to do things.