前言

程序设计中数据库设计很多时候会有多表关联，比如A表的主键是B表的外键。有时候为了不用联合查询还会给某张表设计几个冗余字段方便查询，原则上这几个冗余字段也是作为外键，其他相关表的数据变化这几个字段也会变化。考虑到开发、测试方便以及可能后期数据迁移等，一般数据库设计时不会指定表间关联关系，也不会做触发器来维护上述关联表的数据一致性。数据变化的逻辑由代码去维护。

问题

.Net在使用EF开发过程中，（不考虑直接写一串SQL），假设有学生表（id主键，学号）和成绩表（id主键，学生学号（不考虑设计问题，假设这个是冗余字段）。学生表修改学号时，成绩表学号也要跟着变。分层设计时数据访问 （DAL）层 都有对应表的操作方法，业务逻辑层（BLL）引用了DAL层的方法并在这层做逻辑处理，遇到上述问题，我一般在BLL层学生业务相关的地方 修改学生的代码里加入对成绩表的处理逻辑。 但是很多时候我看到其他人的代码是直接把逻辑写在Controller层里，Controller里除了引入BLL还引入了DAL,controller里混合调用了两层的方法，我想请教下严格意义上来说这样是否有问题。逻辑是否一定要在业务逻辑层里维护？还有如果引入DTO的设计，那BLL的Model和DTO的转换放在Controller里好还是在BLL里好一点？
请不要说你写代码自己决定之类的话，我想要个正确的答案...