AFCStudio C 后端测试任务实战指南:基于 .NET Core 与 CQRS 的员工管理服务
教程【免费下载链接】ru-test-assignmentsТестовые задания для самостоятельного выполнения от разных it компаний项目地址https://gitcode.com/gh_mirrors/ru/ru-test-assignments点击查看免费下载导读本文基于 csharp/afcstudio/0621204ce249e9faf1aaa1e1b7d3f7ef.md 整理成稿全面拆解 AFCStudio 面向 C# Junior Backend / Full-stack 候选人的技术测试题用 C#.NET Core 5与 CQRS 架构实现一个带职位、可按职位自动核算薪资的员工管理服务并附赠 SQL 脚本任务与可选的前端单页应用扩展。读完本文你将掌握该任务从领域建模、API 设计、分页排序过滤到 SQL 脚本与前端异步交互的完整落地思路可直接作为完成该测试任务的实现蓝图。一、任务全景与技术栈要求原任务要求实现一个「组织员工管理服务」核心约束如下维度要求后端语言/框架C#.NET Core 5 及以上版本架构风格CQRS命令查询职责分离数据库Microsoft SQL Server 或 PostgreSQL前端可选附加题技术不限Angular / React / Razor 等均可任务由三部分组成主任务后端员工 CRUD 服务 支持分页、排序、过滤的查询接口数据库任务编写并提交 4 条 SQL 脚本查询、筛选、删除、更新附加任务可选一个带横向导航的站点员工表格 模态窗 全异步交互。从仓库同类别任务看这类测试题普遍要求「可运行 可验证 文档完备」。例如 backend/java-time-tracker.md 中同样强调 RESTful/HTTP/JSON、README 需说明构建步骤与持久化数据位置、并建议附带 OpenAPI 规范与测试。AFCStudio 任务虽未明文要求但遵循同样的工程化交付标准README、迁移脚本、测试、Swagger会让方案显著加分。二、主任务员工管理服务的设计要点2.1 领域模型员工与职位核心业务规则是员工必须拥有职位должность薪资заработная плата基于职位自动计算。这决定了数据模型至少要拆成两张表职位表Position/JobTitle存储职位名称、薪资计算基准。薪资与职位绑定后后续新增「按职位调薪」只需改职位表无需逐员工更新。员工表Employee至少包含 ФИО姓名字段中文语境下可拆 first_name/middle_name/last_name 或直接存 full_name、出生日期、入职日期、所属部门、职位外键。薪资计算逻辑建议收敛在领域层或服务层例如职位表存基础薪资字段员工创建/编辑时由该字段派生Salary若需要更复杂的规则级别、工龄系数可在此处扩展策略模式。2.2 API 设计围绕 CRUD 分页查询可设计如下 REST 端点方法路径说明GET/api/employees分页查询支持排序与过滤GET/api/employees/{id}查询单个员工POST/api/employees创建员工PUT/api/employees/{id}更新员工DELETE/api/employees/{id}删除员工分页 排序 过滤是主任务中最容易暴露细节差异的部分建议统一收敛为查询参数page页码从 1 或 0 开始需在 README 中明确、pageSize每页条数建议设上限防止全表拉取sortBy如name/position/hireDate与sortOrderasc/descfilter按ФИО 员工或职位过滤原题明确要求这两个过滤维度可分别提供searchName与positionId或positionName参数。响应体建议统一包装为PageResultT当前页数据 总条数 总页数便于前端渲染分页器服务端尽量在数据库层完成ORDER BY/WHERE/LIMIT OFFSET避免内存分页。2.3 为什么用 CQRS任务考察的架构意图CQRS 将「写模型Command」与「读模型Query」分离写侧以命令形式表达业务意图CreateEmployee、UpdateEmployeeSalary读侧以查询模型直接响应 UI 诉求EmployeeListQuery。在该任务中的收益是员工创建/编辑涉及「职位→薪资」派生规则适合放进 Command Handler 统一处理保证写路径单一入口列表页的排序、过滤、分页是典型的读优化场景Query Handler 可以返回扁平化 DTO预 JOIN 出职位名、部门名避免把领域实体直接暴露给前端读写分离后写模型可以走 MSSQL/PostgreSQL 事务读模型后续甚至可以引入物化视图或缓存扩展空间更大。落地方案可参考常见组合ASP.NET Core Web API MediatR或自建 dispatcher实现 Command/Query 分发 EF Core或 Dapper访问数据库。需要注意CQRS 不代表必须拆成两个数据库单体应用内部分层实现读写模型分离即可满足考察意图。2.4 数据访问与迁移数据库选型MSSQL 与 PostgreSQL 二选一即可。若用 EF CoreUseSqlServer/UseNpgsql仅差一个提供程序配置业务代码不变建议把连接字符串放到appsettings.json并通过环境变量覆盖。迁移提交初始迁移EF CoreAdd-Migration InitialCreate或等价 SQL DDL保证评审者能一键建库这与 backend/java-time-tracker.md 中「README 说明建库与启动过程」的验收口径一致。种子数据预置几条职位与员工数据便于评审直接体验分页/排序/过滤效果。三、数据库任务四条 SQL 脚本逐一实现原题要求「编写并附上脚本」这是独立的 SQL 能力考察与后端代码解耦。假设员工表名为employees、薪资字段为salary、出生日期字段为birth_date四条脚本的标准实现如下-- 1) 选择所有员工可按需要 JOIN 职位表补充职位名 SELECT * FROM employees; -- 2) 选择薪资高于 10000 的员工 SELECT * FROM employees WHERE salary 10000; -- 3) 删除年龄超过 70 岁的员工birth_date 为出生日期 DELETE FROM employees WHERE birth_date CURRENT_DATE - INTERVAL 70 years; -- PostgreSQL 语法 -- 4) 将薪资低于 15000 的员工统一更新为 15000 UPDATE employees SET salary 15000 WHERE salary 15000;各脚本的考察点与注意事项脚本核心考察点全量查询基础 SELECT 语法是否需要 JOIN 由表设计决定salary 10000严格大于不含等于的边界理解注意与的区别年龄超过 70日期运算应按出生日期 当前日期 - 70年计算而不是「年龄字段 70」PostgreSQL 用CURRENT_DATE - INTERVAL 70 yearsMSSQL 用DATEADD(YEAR, -70, GETDATE())提交脚本时应注明目标数据库批量更新WHERE salary 15000精确圈定目标行UPDATE 不遗漏也不越界实际项目里「删除 70 岁以上员工」通常属于高危操作评审可能额外追问是否应改为软删除加is_deleted标记或先 SELECT 确认影响行数。可在提交说明中补充事务与确认建议体现工程意识。四、附加任务前端站点可选加分项原题明确这是「按意愿执行」的附加题技术栈不限Angular / React / Razor 均可核心要求如下横向导航菜单两个标签页「О компании」关于公司——起始页任意排版「Сотрудники」员工——数据表格页。表格列Отдел部门、Ф.И.О姓名、Дата рождения出生日期、Дата устройства на работу入职日期、Заработная плата薪资。操作列表头留空表体每行三个按钮——「Создать/Редактировать/Удалить」创建/编辑 → 弹出带员工字段的模态窗删除 → 弹出确认模态窗。所有操作必须异步完成页面不刷新。4.1 实现建议框架选型React TypeScript 或 Angular 均能胜任Razor Pages fetch 也满足要求可结合自身熟悉度选择。仓库内 frontend/fractal-web/front-test-assignment.md 展示了同类任务对模态窗与表单校验的考察口径可参考其「禁用第三方 UI 组件、自行实现模态窗」的严格要求来提升完成度。异步交互表格数据通过fetch/axios调用/api/employees携带分页/排序/过滤参数创建、编辑、删除分别调用对应 REST 端点成功后局部更新表格状态而不是location.reload()——这是「不刷新页面」的验收关键。模态窗状态用组件状态React 的useState或 Angular 的组件字段控制「关闭 / 创建 / 编辑 / 删除确认」四种形态创建与编辑复用同一套员工表单部门、姓名、出生日期、入职日期提交成功后关闭弹窗并刷新列表。与分页接口联动前端表格宜同时展示页码控件与排序/过滤控件直接对接后端GET /api/employees的参数串起主任务与附加任务的闭环。五、交付物清单与验收建议综合原题全部要求建议最终交付以下内容后端解决方案ASP.NET Core Web API.NET Core 5CQRS 分层Command/Query HandlerEF Core 迁移脚本SQL 脚本文件四条查询/更新/删除脚本单独成文件注明目标数据库语法MSSQL 或 PostgreSQL前端站点可选两标签页导航 员工表格 模态窗全异步交互README说明技术栈、启动步骤数据库连接、迁移、运行、API 端点清单——参考 backend/java-time-tracker.md 中对 README 完备性的验收要求构建步骤、持久化数据位置、日志位置测试加分项针对薪资计算规则、分页边界、四条 SQL 逻辑写单元/集成测试。六、常见坑位提醒薪资派生逻辑散落若在 Controller 里手动算薪资就失去了 CQRS 把业务规则收敛到 Command Handler 的意义务必让「职位→薪资」只存在于写侧单一入口。分页参数语义不清page从 0 还是 1 开始、pageSize是否限长应在 README 与 Swagger 中写清楚否则前端对接必踩坑。SQL 日期比较删除 70 岁以上员工时用「出生日期字段」与当前日期做差值而不是依赖冗余的 age 字段同时确认目标库的日期函数语法。异步操作的反馈模态窗提交后需给出 loading/成功/失败状态删除前必须二次确认这是附加题体验分的重点。总结AFCStudio 这道 C# 测试题覆盖了后端 CRUD、CQRS 架构、分页排序过滤、数据库脚本与前端异步交互五个技术面属于典型的「小而全」全栈考题。按本文梳理的领域模型、API 设计与交付清单推进即可在满足原题全部硬性要求的同时通过迁移脚本、测试与 README 展示出 Junior 以上水准的工程素养。原始题目与完整要求见 csharp/afcstudio/0621204ce249e9faf1aaa1e1b7d3f7ef.md。赞分享教程【免费下载链接】ru-test-assignmentsТестовые задания для самостоятельного выполнения от разных it компаний项目地址https://gitcode.com/gh_mirrors/ru/ru-test-assignments点击查看免费下载相关推荐Pixlpark 后端测试任务实战指南基于 ASP.NET Core 与 RabbitMQ 的邮箱验证码注册系统Pixlpark 后端测试任务实战指南基于 ASP.NET Core 与 RabbitMQ 的邮箱验证码注册系统 本篇技术指南围绕开源仓库 ru test a教程Three.js加载外部模型终极指南OBJ与GLTF文件导入技巧Three.js加载外部模型终极指南OBJ与GLTF文件导入技巧 在Three.js 3D开发中 加载外部模型 是创建丰富三维场景的关键技能。无论是游戏开发RIOT nanocoap 服务器实战指南基于 sock API 的 CoAP 服务端从零实现与测试RIOT nanocoap 服务器实战指南基于 sock API 的 CoAP 服务端从零实现与测试 本文以 RIOT 仓库中的 examples/netwo物联网嵌入式操作系统实时系统创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考