当我们有了概要需求分析，有了架构规划，如果项目不是很复杂其实已经可以开始进行开发了，本项目还需要进行一些详细的需求分析以规划具体的开发任务。由于需要赶项目进度，拿出一个可供演示主要功能的版本，因此我将会先跳过登录系统的开发，首先完成下订单以及远程打印的功能。
完整订单流程分析
让我们以一张时序图来说明业务流程：
其中主要有四个明显用例：
- 下订单：用户提交订单请求，包括有每个文件具体的打印配置（例如单双页、纸张大小、彩印或黑白等），服务端根据订单请求生成一份订单，并返回订单详情，订单详情说明了订单的各项信息包括费用；用户端在收到订单详情后自动将文件上传至文件端并换取文件标识，接着用户端将文件标识交付给服务端进行验证，若验证通过即可进行付款等后续工作。若因用户操作导致文件上传失败或是验证不通过，则可以手动重新上传文件。
- 付款：用户在订单验证通过后，即可进行付款，付款成功之后，服务端将会发送打印请求，控制订单对应的打印端进行打印。打印端接到打印请求后，从文件端下载需要打印的文件，并根据打印请求中的打印配置放入打印队列进行打印。
- 打印状态查询：用户可以向服务端查询订单的打印状态。
- 打印状态刷新：用户可以要求服务端刷新订单打印状态，服务端接到刷新请求后向打印端请求打印状态并进行状态刷新。
还包括两个隐含用例：
- 定期更新打印状态：打印端会定期回馈打印状态给服务端。
- 打印完成通知：打印端在订单打印完成后向服务端更新打印状态，服务端向用户推送打印完成通知提示。
柿子要挑软的捏
不难看出，在整个流程中，文件端的功能是最少的，因此也是最容易实现的，我将会以文件端为突破口，逐步构建起这个系统。
文件端有两个明显的功能，即收集文件和提供文件下载服务。此外还需要有一个很难想到的功能——文件格式转换。
为什么需要格式转换呢？
在我们使用Office套件、PDF浏览器等文档查看软件甚至是Web浏览器进行打印时，这些软件似乎可以直接把各种各样的文件直接传送到打印机进行打印，不了解的人会认为我们的操作系统天生就支持这些格式的打印，只是这些软件在调用系统提供的API而已。实际上支持常见格式文件的打印功能都是由这些软件实现的，这些软件首先读取各种文件，然后按照一定的规则进行渲染，接着把渲染后的结果递交给操作系统（你可以简单理解这里的渲染结果是一张张图片），操作系统再进行打印操作。
因此，如果我们想要实现自动打印，也就是不需要商家手动打开文件就能进行打印，一个最直接的方法就是让我们的程序像Office那样自行渲染然后打印，但由于要支持的格式很多，而且每种格式都有自己的标准和渲染方法，这显然不是本系统需要关注的内容，也非一两个人几天就可以做出来的。因此我们必须要寻求外部支持，找到能够替我们执行这部分任务的部件或者一个可行的解决方案。
技术可行性分析
我在经过大量调研，查阅各种资料后了解到的好的解决方案有两张。
打印方案
第一种方案，打印端可以引入一个PDF渲染组件，让这个组件来实现我们上述所讲的直接解决方案，接着通过该组件的一些接口进行输出，并传递给操作系统进行打印。谷歌开源了Chrome中使用的PDF渲染引擎PDFium，基于该渲染引擎有一个开源库PdfiumViewer，利用该开源库即可在.Net下渲染PDF文件。这种解决方案需要本系统将文件统一转换为PDF文件才能下发给打印端进行打印。还有一个问题是PdfiumViewer项目已经不再维护了，意味着将不会有bug修复或是安全更新等支持，但考虑一般业务环境这不是一个特别大的问题（尽管后果可能会很严重但可能性非常之低）。
另一种方案，Windows提供的打印接口中，明确支持了微软自己的一种类似PDF的打印格式XPS，只需要提供XPS格式文件即可进行打印。这种格式不太常见，是微软为对抗PDF而推出的，很明显最后赢家依然是PDF。在.Net 6.0中，微软提供了对XPS打印的支持（见Printing documents overview – WPF .NET | Microsoft Docs），通过调用.Net提供的API即可完成对XPS文件的打印。这种方案需要本系统将文件统一转换为XPS文件才能下发给打印端进行打印。
转格式方案
两种方案都需要进行格式转换，看来格式转换是一个必须的功能了。考虑格式转换这一问题，又有一些问题需要处理。
一般而言，类似本系统，都需要提供一些常见格式的支持，例如Office家族的文档格式（doc/docx、xls/xlsx、ppt/pptx）、PDF文档、图片文档以及纯文本格式（txt）等，这几类几乎覆盖了99%以上的业务场景，因此首先要考虑的就是这些格式的转换。
最复杂的当然是Office格式家族，市面上可以选择使用的格式转换库要么支持有限（例如NPOI），要么需要付高昂的费用（例如Aspose、Spire）。此外还有一种方式，就是依赖Office软件或是WPS软件，通过调用这些软件的接口进行转格式，但是需要注意的是一般这些接口都不是对外开放的接口，实际商用可能会有风险。本项目作为一个学习项目，并非是要以此盈利，综合各方面成本考虑采用调用Office软件进行格式转换的方案。
下单活动详细需求分析
为了明确文件端提供的服务，我们还需要进行一些详细需求分析。
本系统希望能够允许用户以较大的灵活性进行下单，因此有以下需求：
- 用户下单时，允许一个订单包含多个打印文件，并对每个文件进行单独的打印配置
- 每个订单的每个文件都会在下单后自动上传，若用户打断上传，则需要用户重新上传传送失败的文件
- 每个文件需要有状态提示，包括待上传、上传失败、转换中、上传成功、排队中、打印中、待取中、完成
- 每个订单都有订单状态来提醒用户当前的情况，包括待上传、待支付、转换中、打印中、待取中、完成
- 订单状态部分依赖于每个文件的状态，当用户全部上传完文件后订单转为待支付，当用户支付完成后若有文件尚在转换中，则订单状态为转换中
