Data Transfer Objects VS Domain/ActiveRecord Entities in the View in RoR

I'm coming from a .NET background, where it is a practice to not bind domain/entity models directly to the view in not-so-basic CRUD-ish applications where the view does not directly project entity fields as-is.

I'm wondering what's the practice in RoR, where the default persistence mechanism is ActiveRecord. I would assert that presentation-related info should not be leaked to the entities, not sure though if this is how real RoR heads would do it.

If DTOs/model per view is the approach, how will you do it in Rails?

Your thoughts?

Some examples: - A view shows a list of invoices, with the number of unique items in one column. - A view shows a list of credit card accounts, where possibly fraudulent transactions are executed. For that, the UI needs to show accounts that have more than one transaction in red.

For both scenarios, The lists don't show all of the fields of the entities, just a few to show in the list (like invoice #, transaction date, name of the account, the amount of the transaction)

For the invoice example, The invoice entity doesn't have a field "No. of line items" mapped on it. The database has not been denormalized for perf reasons and it will be computed during query time using aggregate functions.

For the credit card accounts example, surely the card transaction entity doesn't have a "Show-in-red" or "IsFraudulent" invariant. Yes it may be a business rule, but for this example, that is a presentation concern, so I would like to keep it out of my domain model.

EDIT: A new example:

    //The persistent/Domain model, can be implemented as AR in RoR

public class Bus : Entity
{   
    public int BusNo { get; set; }
    //to represent a one-to-many association mapping    
    public IList<Person> passengers {get; set;}

//to represent many-to-one association mapping
    public Person driver {get; set;}
    public LtfrbFranchise permit {get; set;}
    public Location currentLocation {get; set;}

//other data fields/association mappings

public void AddPassenger(Person pax){
        pax.Ride(this);
        passengers.Add(pax);        
    }

public bool IsColorum(){  
        return !permit.AllowsTripOn(currentLocation);                       
    }

public bool IsOverloading(){
        return (passengers.Count() > permit.SeatingCapacity);
    }
}

//The UI only requires the following:
[Serializable]
public class BusListDTO
{  
    public int BusNo {get; set;}  
    public string DriverName {get; set;} //from Bus.driver.LastName + "," + Bus.driver.FirstName
    public bool ShouldBeDisciplined {get; set;}  //this is TRUE when both IsColorum() and IsOverloading() of Bus are TRUE. If TRUE. a grid row should show 3 buttons.
}

BusListDTO can be used to show information to the UI, or serialize it as JSON/XML should the need arises.

Without a DTO, the entity/AR will have a lot of members that are not really persisted since the entity evaluates them for every call. Some examples:

• You can add a DriverName attribute to the Bus entity but the attribute DriverName is a presentation concern.
• You can add ShouldBeDisciplined to the Bus entity, perhaps persist it to save up on DB roundtrips.

Should the Bus entity be involved in a lot of views that does not directly show its shape, you end up with a monolithic AR class. In a large team scenario, this is a maintenance nightmare, where you spend a lot of time communicating what attributes do in specific use-cases and you have devs who use attributes indiscriminately.