移动“逻辑”脱离数据访问层会导致大量的数据库连接
我的数据访问层中有一个方法可以处理文件导入。这样的文件中可以有许多需要插入数据库的记录。 该方法已经包含某些“逻辑或业务规则”，还需要添加更多内容。 问题是，如果我将其移出数据访问层，则必须使用新连接单独插入每个记录。显然，当插入数千条记录时，这不是很好。 （不保证连接被池化）。 所以我有点不知道如何解决这个问题。数据访问层类变得越来越大，就良好的设计操作系统而言，可能已经违反了一些规则。
我唯一想到的是生产者-消费者 ->业务逻辑导入文件并执行验证并将验证的记录放入队列中。一个单独的线程（数据访问层）从该队列中读取。
还有其他想法吗？此类问题有模式吗？
I have a method in my dataaccess layer that processes a file import. Such a file can have many records in it that need to be inserted into the database.
This method already contains certain "logic or business rules" and more need to be added.
Problem is if I move this out of the dataaccess layer each record would have to be inserted separately with a new connection. Obviously that is not very good when inserting thousands of records. (there is no guarantee that connections are pooled).
So I'm kind of lost on how to solve this. The dataaccess layer class is getting bigger and bigger and in term of good design os probably violating several rules already.
Only thing that comes to my mind is producer-consumer -> business logic imports file and performs validation and puts validated records into a queue. A separate thread (the dataaccess layer) reads from that queue.
Any other ideas? is there a pattern for such problems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你有一个设计问题。业务逻辑层应该是划分事务的层，数据访问层应该始终对给定事务使用相同的连接。
例如，您可以使用 Spring，它允许您使用声明性事务和连接池，并确保整个事务使用相同的连接。
You have a design problem. The business logic layer should be the one demarcating transactions, and the data access layer should always use the same connection for a given transaction.
You could be using Spring, for example, which would let you use declarative transactions and a connection pool, and would make sure the same connection is used for the whole transaction.