您可能希望了解Command-Query Segregation。基本上这归结为几个概念:
因此,为了保存用户的数据,您将获得控制器中的文件/数据,并将其传递给处理此类数据的命令。对于导出,您可以在控制器中执行查询,查询将从DB中提取数据并进行适当格式化。
有时,如果您将数据提取为XLS或其他格式,则可能需要引入单独的渲染器。这样您的关注点就会分开 - 查询只提取数据,渲染器将该数据转换为所需的格式。这样,您只需添加新的渲染器即可将数据提取为不同的格式。
命令也是如此 - 命令的一部分可以是解析器,它将传入的数据解析为类实例,然后命令将其保存到DB中。
您可以在此处查看示例和更多CQRS详细信息:
这看起来并不那么糟糕。有两个命名问题,特别是您的控制器不是控制器而是 的 资料库 强> 你的输出类是一个 的 服务 强> (以便 OutputService 会是一个更好的名字)。
OutputService
分层是好的。你有一个很深的领域模型。然后你在上层有一个存储库,在它上面有你的服务。如果您遵循存储库类名称结尾的简单约定 Repository ( OrderRepository )和服务 ..Service 并且您将每个图层放在一个单独的组件中,并允许上层组件仅引用下层组件,然后您将清除大部分混淆。
Repository
OrderRepository
..Service
我的想法是不要手工编写模型类和存储库。由于存在很多陷阱,这没有多大意义。相反,使用Entity Framework反向工程代码优先选项将您的模型从数据库中反向工程,然后使用Entity Framework代替创建存储库。手动创建的唯一层是服务层,您可以在其中实现特定的业务流程。