我認爲你的意思是DDD而不是TDD,因爲你所說的在TDD上沒什麼意義。
你需要坐下來思考一個文件對你的系統意味着什麼,是否有任何連接文件和文章的規則。例如,如果我們刪除一個文章應該有什麼文件?我們也刪除它們嗎?我們能否將相同的文件添加到多個帖子中?你坐下來思考並收集關於你的文件的知識,然後你決定是否值得在你的域名中引入一個地方。
一些樣品域名我可以想像:
public class Post
{
private List<File> _files;
public IEnumerable<File> AssociatedFiles {get {return _files;}}
public void AssociateFile(File file){//...}
public void DisassociateFile(File file){//...}
//It doesn't delete it just do some logic. Maybe we can't delete this post and need to throw exception or whatever logic you need
public void Delete()
{
foreach (File file in AssociatedFiles) DisassociateFile(file);
}
}
public class File
{
public String Url;
public DateTime Created;
public DateTime Modified;
}
public class PostRepository
{
public void Delete(Post post)
{
post.Delete();
DbContext<Post>.Delete(post); //I Don't remember EF syntax for this
DbContext.SaveChanges();
}
}
更新:讓我們繼續...
思考你域我descovered的5分鐘後,我最初的設計錯過重要的概念(像DDD一樣,你一點一點地颳去知識)。
誰負責上傳文件?用戶可以將他已經上傳到Post的文件關聯,他可以添加新的File(unuploded)文件嗎?他可以混合這些東西嗎?這些都是重要的問題,你需要考慮並設計你的系統。
這個問題聽起來像流行語賓果:) – ThiefMaster 2012-04-14 09:06:12