Saving Composite Data Model

I have a composite data model defind as:

class DocumentModel{

string _name;

List<PermissionModel> _permissions;

}

Currently I have two classes in my DAL one handling the core document information (in the example above, Name), and another handing permission related data.

So to successfully save a DocumentModel, I would have to make at a minimum 2 trips to the database (assuming I can bulk save List<PermissionModel>).

Suppose I to want to improve my current design pattern, would the following methods be better or worse

1) Have a single class in the DAL that takes in the entire Document model and calls the DB once with 2+ commands (1 to save Name, and more to save permissions one at a time). I believe this method will increase performance (making the app less chatty), but will be harder to maintain (if we change the permission table, we'll have to propagate the change to more than 1 DAL class).

2) Still have two class (one for core Document data, one for permissions), but have a primary/seconday relationship using transaction. In other words, my DocumentService will still call DAL.Document sending it the Document model along with the permissions inside, but then, DAL.Document would call DAL.Permission(passing it the SqlTransaction object) so that when DAL.Document is ready to go to the DB, it only takes 1 trip. I think this method is a pretty good hybrid method since it still allow my DAL classes to keep their atomic nature and yet, allow me to make my app less chatty. Haven't looked into TransactionScope yet, but technically, can I create the TransactionScope object in DAL.Document then call DAL.Permission to tie to two together

Is method 2 good, bad or ugly

Best,

Jason