ASP.NET Core MVC本地数据库备份与模型控制器迭代问题咨询

问题1：LocalDB数据库迁移备份相关 #

核心疑问答复 #

• 不能仅通过修改连接字符串的名称和路径完成完整数据迁移备份，当前你的mdf文件属于已挂载到LocalDB运行实例的状态，直接复制文件本身无法保证数据完整性。
• 文件被占用的原因：对应的MSSQLLocalDB实例的运行进程sqlservr.exe持有mdf、ldf文件的独占锁，你直接操作文件系统复制会被系统拦截。

简单备份方案 #

方案1：停实例后复制文件（适合快速本地备份）

1. 打开命令提示符/ Powershell，执行命令停止LocalDB实例：
   SqlLocalDB.exe stop MSSQLLocalDB
2. 到对应存储路径下复制.mdf和对应同名.ldf文件到备份路径
3. 执行命令恢复实例运行：
   SqlLocalDB.exe start MSSQLLocalDB
4. 后续要使用备份的数据库文件时，在连接字符串中增加AttachDBFilename=你的备份mdf文件完整路径参数即可挂载使用。

方案2：SQL原生备份（更稳妥，适合生产/跨设备迁移）

打开Visual Studio的SQL Server对象资源管理器/ SSMS，连接到(localdb)\mssqllocaldb实例，选中目标数据库后右键选择「任务」→「备份」，指定备份文件存储路径即可完成备份，还原时直接选择备份文件恢复即可，不需要停实例，也不会出现文件损坏问题。

问题2：模型变更与自动生成代码冲突解决方案 #

代码层面避免覆盖方案 #

• 不要直接在自动生成的控制器中写自定义业务逻辑，也不要直接绑定实体模型到入参：单独创建视图模型(ViewModel) 对应每个接口的入参/出参，比如创建操作单独建CreatePersonViewModel，只放该操作需要的字段，控制器入参直接用该视图模型，不需要写Bind特性，既避免过绑定安全问题，也不会和自动生成的实体模型代码耦合。
• 把业务逻辑抽离到单独的服务层类中，控制器仅做参数校验、调用服务、返回响应，就算后续需要重新生成控制器的脚手架代码，只要把服务调用逻辑补回即可，不会丢失自定义逻辑。
• 若需要保留自动生成的控制器基础代码，可以把自定义逻辑写到分部类（partial class）中，和自动生成的控制器类分部拆分，重新生成脚手架代码时不会覆盖分部类的内容。

数据库变更避免数据丢失方案 #

所有模型的结构变更都通过EF Core的迁移（Migration）功能实现：

1. 每次修改模型类（新增字段、修改列名、调整约束等）后，在包管理器控制台执行：
   Add-Migration 自定义迁移标识名（比如Add_Person_PhoneNumber）
   EF Core会自动对比当前模型和数据库结构的差异，生成对应的变更脚本。
2. 确认变更无误后执行：
   Update-Database
   即可完成数据库结构的平滑升级，默认不会修改、删除现有数据。如果担心变更有风险，可以先执行Script-Migration生成纯SQL脚本，人工检查确认没有破坏性操作后再手动执行SQL即可。

内容的提问来源于stack exchange，提问作者Reem Al-Assaf