Should we do projection and formating kind of activity in database layer

Question

I am doing code review of following code written by my colleague and as per my experience projection and formatting kind of activity should not be done in DB layer instead should do it in business layer. But he is not convinced. This DB layer is for mvc application.

Please suggest me is following codes are OK or we should always avoid projection/formatting in DB layer.

    public class CustomerDetails
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Address1 { get; set; }
        public string Address2 { get; set; }
        public string City { get; set; }
        public string State { get; set; }
        public string Country { get; set; }
        public DateTime PurchaseDate { get; set; }
        public Decimal OrderAmount { get; set; }
        //more propery...

    }

    public class CustomerRepository
    {
        public IEnumerable<CustomerDetails> GetCustomer(int customerID)
        {
            //get data using entity framework DBContext
            IEnumerable<CustomerDetails> customer = get data from database using sqlquery;
            //projection and formatting
            return customer.Select
            (p =>
                new CustomerDetails
                {
                     FirstName=p.FirstName.ToProper(), //extension method
                     LastName = p.LastName.ToProper(),
                     Address1 = p.Address1,
                     Address2=p.Address2,
                     City = p.City.ToProper(),
                     State=p.State.ToUpper(),
                     PurchaseDate=p.PurchaseDate.Tommddyyy(),
                     OrderAmount=p.OrderAmount.ToUSA()
                }
            );
        }
    }

UPDATE:

CustomerDetails is db entity which maps field return by stored procedure. We are using repository to put a abstraction layer on ORM(EF) so that if we need change our ORM framework it should not impact on dependent layer.

What i thought, from repository we should return row data and different representation of same data should be done in service layer.

Answer 1

I would say that where to put this kind of code might be a design decision depending on what's the actual case.

Furthermore, when using OR/M frameworks I doubt that there would be a database layer at all, since any OR/M tries to be a data layer itself, and they tend to provide a Repository Pattern-like interface to query and write persistent objects. That is, since a repository is a collection-like interface which translates the underlying data format to domain objects (entities), it seems like whatever you call your layers they will be still the domain/business layer, or maybe the service layer - who knows -.

Also, your code seems to be a repository (!) and this means that we're not talking about a database layer. Instead of that, we're talking about the boundary between the domain and the data mapper (OR/M, i.e. Entity Framework).

TL;DR

If the whole repositories require some kind of projection, meaning that these projects are the domain objects expected by the domain layer, I find that such projections are implemented in the right place.

After all, as I said in the long text above, I don't see a data/database layer in an OR/M-based solution at all...