NET作为微软家的老牌框架，用来搭建B2B平台其实挺合适的，但前提是你得知道哪些功能才是真正核心的。今天我就结合自己踩过的坑，聊聊用ASP.NET构建B2B平台时那些必须搞明白的关键点。
B2B平台和B2C最大的区别就在于用户角色太复杂了。你想想，一个采购商可能同时是多个企业的采购代表，而一个供应商又可能有不同的销售团队对接不同客户。在ASP.NET里，我一般会采用基于角色的访问控制加上用户组的概念，再配合自定义授权过滤器来实现精细化管理。
具体操作上，我会先在数据库里建好用户表、角色表、用户组表，然后通过中间表建立多对多关系。在代码层面，利用ASP.NET Core内置的Identity框架进行基础身份验证，再通过自定义的Policy-based Authorization来处理那些特殊的业务规则。比如某个供应商只能看到自己授权过的产品目录，这类需求用Claims-based方式处理就特别顺手。
实际开发中，我建议把权限判断的逻辑封装成一个服务层，这样控制器里就只用调用一个方法，代码干净很多。另外，测试环境里一定要模拟各种极端情况，比如同时有多个角色重叠的用户操作，不然上线后很容易出权限泄露的bug。
B2B的产品管理可比零售复杂多了。同一个产品，针对不同客户可能价格不一样，甚至显示的产品参数都有差异。我在做ASP.NET项目时，通常会用产品模板加上价格规则引擎来解决这个问题。产品模板定义基础属性，价格规则引擎则根据客户等级、采购数量、合同期限等条件动态计算价格。
在数据库设计上，我会把产品属性拆成主表和扩展属性表，这样既能保证查询效率，又方便后期添加新属性。
价格方面，建立价格表、客户价格表、促销价格表三张核心表，通过优先级机制来决定最终生效的价格。比如客户价格表的优先级高于基础价格，促销价格又高于客户价格。
ASP.NET的强类型视图模型在这里特别有用，我可以为不同的产品类型创建不同的视图模型，前端展示时直接绑定对应的属性，不用在视图里写一堆判断逻辑。说实话，这个设计思路一开始可能觉得麻烦，但后期维护起来真的省心，特别是当产品种类增加到几百种的时候。
B2B的订单流程经常涉及多级审批、分批发货、信用额度检查等复杂逻辑。我见过不少团队直接在控制器里写if-else来处理这些流程，结果代码变得又臭又长。其实ASP.NET生态里有很多成熟的工作流引擎可以用，比如Workflow Core或者Elsa，把这些业务规则抽象出来会好很多。
我自己比较倾向于用状态机模式来设计订单状态流转。每个订单状态定义好允许的操作和下一个状态，审批环节就作为状态变迁的触发条件。在ASP.NET Core里实现这个模式挺方便的，用枚举定义状态，再用一个服务类来管理状态变迁的规则，每个变迁动作对应一个方法，方法里处理具体的业务逻辑。
举个例子，当采购订单提交后，系统自动检查订单金额是否超过信用额度，如果超过就进入待审批状态，否则直接变成已确认。这些逻辑用工作流引擎来表达，比硬编码清晰得多。而且以后业务变化时，只需要修改工作流定义文件，不用动核心代码，维护成本低不少。
B2B平台的数据报表是客户非常看重的功能，但也是最容易拖慢系统性能的地方。我之前有个项目，客户要求实时查看所有历史订单的统计报表，结果数据库差点被查崩溃。后来我学乖了，把报表查询和业务查询彻底分开，用专门的报表数据库或者缓存机制来处理。
在ASP.NET里，我通常会为报表功能单独建立一个Web API项目，使用只读的数据库副本或者内存缓存来提供数据。对于需要实时更新的少量数据，用SignalR推送最新变化；对于历史数据的统计，则采用定时任务生成报表快照，用户查询时直接读取快照数据。这样既保证了数据的新鲜度，又不会影响核心业务的性能。
还有一点很重要，给报表查询设计合适的索引。我发现很多开发者喜欢在开发环境测试，数据量小看不出问题，但一到生产环境，几百万条数据一跑，慢查询就全暴露了。建议在开发阶段就用数据量接近生产环境的测试数据，配合SQL Server的查询分析工具优化索引。说实话，这个习惯养成后，能避免很多上线后的性能事故。
