Question

Should the following GetPhycialFileLocation() method in the Car class have it's own Service Layer?

public class Car
{
    public int id;
    public string model;
    public int year;
    public IList<Pic> lstCarPics;
}

Then we have the respective class:

public class Pic
{
    public string filename;
    public string fileLocation;
    public string GetPhysicalFileLocation()
    {
        string LocalDirectory = "~\\CarFiles\\";
        DirectoryInfo diPath = new 
            DirectoryInfo(HttpContext.Current.Server
                         .MapPath(LocalDirectory + car.id);
    }
}

Seeing that this method and others will access physical file locations throughout the application, would something like this justify having it's own FileService?

I'm having trouble understanding when methods like this should fall under it's own service layer vs leaving it in its class.

Was it helpful?

Solution

When running into this kind of doubt it's often useful to think in terms of real objects, their behaviors, and responsibilities, so you could ask yourself:

  • Do pictures look up file locations? Doesn't sound like the behavior one could expect from a Picture or PictureFile.

  • Is a picture responsible for looking up the location where it is stored? I don't think so, maybe a PictureLocator, FileLoader, etc.

Whenever such a method belongs to a service layer, application layer, or even a data layer, depends on your architecture. Although I don't know the details, it seems like quite a simple method to be something of entity in the service layer.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top