Olá, José Luiz!
Esta classe DataService é/ou a mesma classe DAO isso ?
Sim, ela é a classe de serviço de acesso a dados
Não seria o correto manter tudo na classe DataService certo ? seria bom ter ProdutoDataService, PedidoDataService ?
Sim, é uma alternativa, à medida que seu sistema vai crescendo, você poderia quebrar em classes menores para que a classe DataService não acumulasse responsabilidades demais. Como o modelo do curso é pequeno (e continuou pequeno) e não contém muitos métodos, não me preocupei muito em refinar a arquitetura (se bem que poderia ter feito, nem que fosse como uma ilustração). Então sua sugestão é perfeita. Se no futuro tivermos uma continuação do curso ASP.NET Core com essa aplicação, vou conversar sobre essas decisões arquiteturais.
Onde estaria meu método por exemplo produto.Adicionar (que antes ficava na classe DAO), qual a melhor estratégia para isso ? colocariamos na Classe DataService ? ou Criariamos uma service para cada tabela ?
Você pode criar um ProdutoDataService separado, não vejo problemas nisso. Em DataService, seu método tem que se chamar algo como "AdicionarProduto", mas em ProdutoDataService ele pode se chamar simplesmente "Adicionar", o que deixa o projeto mais elegante. E então você pode extrair uma interface e uma classe base abstrata chamada BaseDataService<T>, onde T é a classe do modelo que com a qual vai trabalhar (Produto, Pedido, etc.). Você pode sempre mexer na arquitetura para melhorar o design da aplicação.
Note também que, se precisar quebrar DataService em mais classes, também vai ter que registrar os tipos dessas classes no Startup.cs e passar as interfaces dessas classes como parâmetro nos construtores dos controllers para que a injeção de dependência do ASP.NET Core funcione corretamente.
Boa sorte e abraços!
