Is this method a good candidate for a service layer?
As @Vogel612 hinted, a class shouldn't expose its fields publicly - this:

public class Car 
{
    public int Id { get; set; }

    // ...
}


Is equivalent to this:

public class Car
{
    private int _id;
    public int Id 
    { 
        get { return _id; }
        set { _id = value; }
    }

    // ...
}


As you can see, encapsulation is easily achieved with auto-properties - don't expose your fields!



Method GetPhysicalFileLocation has dependencies on the file system and on an HttpContext, so you definitely want that to be abstracted away, so you can write a test that uses that code and doesn't actually hit the file system.

I'd move it to some IFileSystemService implementation:

public interface IFileSystemService
{
    string GetPhysicalFileLocation(int carId);

    // ...
}


And then make a class that implements it:

public class FileSystemService : IFileSystemService
{
    // load this value from application settings?
    private readonly string _localDirectory = "~\\CarFiles\\";

    public string GetPhysicalFileLocation(int carId)
    {
        var diPath = new DirectoryInfo(HttpContext.Current
                                                  .Server.MapPath(_localDirectory + carId);
    }
}


And now you can have client code like this:

public class MyClass
{
    private readonly IFileSystemService _service;

    public MyClass(IFileSystemService service)
    {
        _service = service;
    }

    public void DoSomething(int carId)
    {
        var fileName = _service.GetPhysicalFileLocation(carId);
        // ...
    }
}


This way you can inject a "fake"/"mock" implementation for IFileSystemService and test DoSomething without hitting the file system or depending on an HttpContext; the key being that depending on the file system and on an HttpContext, is an implementation detail that the client code doesn't need to know about.