在哪里放置文件上传代码的分层架构 [英] Where to place file upload code in there layered architecture

问题描述

在Angular和Web API 2.0中设计Web应用程序的体系结构，Web API也分为2层数据和业务。我想了解，根据良好的架构指南，将文件上传代码放置在业务或数据层中的位置。



我尝试过：



这里的问题是使代码线程安全，我想在开始和提交事务下保存数据库中的发票信息和发票生成（发票文件创建），但是同时我想了解它是否是一个好的方法。

解决方案

为什么让它的线程安全是一个问题？通常，调用由单个线程（旧方式）处理，或者单个异步调用链也可以保护您的代码免受线程问题的影响 - 除非您自己启动线程。



但是由于你想生成一个文件，我看不到上传的位置？



数据层只存储和访问数据。它不具备生成文件等的功能。这意味着业务层必须这样做



在高规模的需求环境中，创建发票文件会可能是在运行队列的后台工作程序中。在小型系统上，您可以在数据插入数据库时​​生成它。如果您不得不提出这个问题，那么在获得更多经验之前，您不应该使用大规模系统。



对于大多数小型系统，您可以逃脱其中一种方法：



生成文件，因为数据存储在系统中。



1 ）启动交易范围

2）插入发票数据

3）生成发票文件（并存储它 - 数据库？文件系统，blob存储，... ）

4）提交交易。通过这种方式，您将获得回滚，即使在磁盘上存储文件失败，也不会存储发票数据，除非您真的不走运（并且您可能真的不太喜欢交易，所以不要担心）



或者你可以选择在读取时生成文件（如果这是可接受的更多是商业问题而不是编程问题）。这种方式它不存储在数据库本身，通常只在文件系统上缓存一段时间 - 如果缓存的话。

1）启动数据库事务

2）存储发票数据

3）提交交易



当API请求进入时，生成文件并将其返回。如果性能显示问题并且您经常收到同一文件的多个请求，则将生成的文件缓存在磁盘上。只记得你仍然必须检查安全性 - 不要只是将文件返回给知道发票号码的最佳来电者（人们将尝试从检索发票的自己的URL中添加或减去发票号码）

Design architecture of a web application in Angular and Web API 2.0,web API is also divided in 2 layers data and business. I want to understand, where to place file upload code in business or data layer as per good architecture guideline.

What I have tried:

The Problem here is to make code thread safe, I want to save invoice information in database and invoice generation (invoice file creation) under begin and commit transaction, but at the same time I want to understand whether it is a good approach or not.

解决方案

Why is it a problem to make it thread safe? Typically a call is processed by a single thread (the old way), or a single async call "chain" that will also protect your code against thread issues - unless you start threads on your own.

But as you want to generate a file, I don't see where upload takes place?

The data layer only stores and access data. It will not have functionality to generate files etc. So that would mean the business layer will have to do it

In a high scale requirement environment, the invoice file creation would probably be in a background worker running of a queue. On small systems you can get away with generating it as the data is inserted in the database. If you have to ask this question you should not be working on a high scale system before you get a bit more experience.

For most small systems you can get away with one of these approaches:

Generate the file as the data is stored in the system.

1) Start transaction scope
2) Insert the data for the invoice
3) Generate the invoice file (and store it as well - database? file system, blob storage, …)
4) Commit the transaction. This way you will get a rollback and the invoice data will not be stored even if storing file on disk fails unless you are really unlucky (and you can be really unlucky with transactions as well, so don't worry about it)

Or alternative you can generate the file on read (if this is acceptable is more of a business question than a programming question). This way it is not stored in the database itself, and is typically only cached on the file system for a short while - if cached at all.
1) Start a database transaction
2) Store the invoice data
3) Commit the transaction

When the API request comes in, generate the file and return it. If performance show a problem and you often get multiple requests for the same file, then cache the generated files on disk. Just remember you must still check security - don't just return the file to the first the best caller knowing the invoice number (people will try adding or subtracting an invoice number from there own URL retrieving the invoice).

这篇关于在哪里放置文件上传代码的分层架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！