No padrão MVC ASP.NET, quero criar uma pasta .DAL somente para representar o BD, é aconselhável?

Olá gente , muito boa tarde!

Estou implementando um projeto com arquitetura MVC, utilizando as pastas model (regras de negócios, métodos, etc),
Controlller (Tratar requisições e validá-las) e a view para apresenta-las, porém, todavia, contudo, fica um linguição fazer acesso ao modelo de dados dentro da pasta models.

Separei uma outra camada .DAL só para tratar as consultas ao modelo de dados. Entretanto, quando vou referenciar a outra camada ocorre o erro de dependência circular: quero que fique assim:
_Migrations
_Model
_Controller
_View
_camada.DAL

Cria um projeto separado pra esse “Model”.
No projeto “DAL” adiciona referencia ao projeto Model.
No projeto Web adiciona referencia ao projeto DAL e Model.

Dessa forma, considerando até onde está mostrando não tem referencia circular.

ótima ideia javaflex, no caso acho que vou chamar o projeto models de BLL e a outra camada obviamente DAL mesmo. Na verdade já tinha tentando isso, mas não estava dando certo com o conceito de code-first, mas não lembro porque agora. Vou fazer isso de toda forma.

Estou na camada BLL, no caso quero dentro de um método x da classe y, chamar um método da camada DAL que retorne um objeto da classe y populado. Como fazer isso se não tenho referência apontando da BLL para a DAL, somente o inverso? Eu usava antigamente uma DTO, para transferência de dados e por isso estou me confundindo.

DataAccess referencia o Model
Business referencia DataAccess e Model

Outra opcao é criar um projeto concentrando todo Dominio e organizar em pastas.

Muito obrigada pela resposta. Acha que usar a camada DTO(camada de transferência de dados), para projetos de médio porte é boa prática no mercado?

Muito obrigada pela resposta. Acha que usar a camada DTO(camada de transferência de dados), para projetos de médio porte é boa prática no mercado?

Nao tem boa prática geral, depende da necessidade, quando tiver a necessidade usa. Só nao pode colocar a tecnologia na frente da necessidade.

No geral nao se prenda a siglas, e sim na funcionalidade, na linguagem do negócio.

Se possível poste como decidiu ficar a estrutura final.