使用Spring / Hibernate,应如何完成这个简单的业务逻辑?

huangapple go评论122阅读模式
英文:

With Spring / Hibernate, how should this simple business logic be done?

问题

有一个简单的项目,包含两个实体:账户(Account)和交易记录(Transactions)。账户实体具有诸如id、账户名称(accountName)和交易记录等字段,而交易记录实体具有诸如id、描述(description)和金额(amount)等字段。

我想要显示一个简单的表格,列出了账户及其在特定年份的现金流(即特定年份内交易总额)。实现这一目标的最佳方法是什么呢?

一种方法是在TransactionService中添加一个类似getCashflow(Account account, int year)的方法,但这需要为每个账户调用一次,并将结果从账户中分离出来传递给模型。

看起来最好的方式是在Account类中添加一个类似getCashflow(int year)的方法,但在不使用TransactionService的情况下如何执行交易总额的求和呢?或者这就是正确的做法吗?如何实现?

我已经看过派生属性,但这不是属性,因为它是特定年份结果的产物。

我知道这个问题似乎很简单,但我无法找出标准方法是什么。

英文:

Say I have a simple project with two entities, Account and Transactions, where the Account entity has fields like id, accountName, and transactions, and the Transaction entity has fields like id, description, and amount.

I want to display a simple table that is a list of accounts and the cashflow for a given year (i.e. the sum of transactions for a given year). What is the best way to achieve this?

One way is to have a method on the TransactionService like getCashflow(Account account, int year), but this requires this to be called for each account and then the result passed to the model disassociated from the Account.

It seems like the best way would be to have a getCashflow(int year) method on Account, but then how can the sum be performed without using the TransactionService? Or is that how it should be done? How?

I have looked at derived properties, but this isn't a property since it is a result of a given year.

I know this seems a simple problem but I can't work out what the textbook approach is.

答案1

得分: 1

代码和代码效率与您设计表(实体)的方式直接相关。

在“账户”表中使用“交易编号”不是一个好主意。这将在账户表中产生许多不必要的条目。相反,将每个交易中的账户数据会更好。

看一下下面的设计:
使用Spring / Hibernate,应如何完成这个简单的业务逻辑?

在所提议的设计中,您可以在“TransactionService”的getCashflow(int year)中调用SUMGROUP BY来编写您的数据库查询。您无需从getCashflow(int year)中引用“账户表”,从而使您的查询更有效,并节省数据库的冗余。

英文:

Code and code efficiency has direct relation with how you design your tables(entities).

Having txn ids in account table is not a good idea. It will have lots of unnecessary entries to account tables. Rather having account data in each txn will be better.

Have a look a the design below:
使用Spring / Hibernate,应如何完成这个简单的业务逻辑?

In the proposed design, you can write your DB query with SUM & GROUP BY called from getCashflow(int year) on TransactionService. You don't have to refer the Account table at all from getCashflow(int year) making your query more efficient and saving you DB from redundancy.

答案2

得分: 1

账户拥有交易,您需要列出带有某些操作(总和)的账户列表,因此必须从AccountService调用类似于getAccountListWithYearlyCashflow(int year)的方法,在该方法中从AccountRepository/数据源检索所有可能的账户,对每个账户获取经过筛选的transactionList并对其进行求和。
由于TransactionService仅处理交易,因此在那里进行任何操作是没有意义的。
希望我正确理解了您的问题 使用Spring / Hibernate,应如何完成这个简单的业务逻辑?

英文:

Account has Transactions, and you need list of accounts with some operations(sum) on transactions, so it must be called from AccountService with method like getAccountListWithYearlyCashflow(int year) and in that method retrieve all possible accounts from AccountRepository/datasource and for each account get filtered transactionList and perform sum on it.
As the TransactionService is dealing with only transactions, it does not make sense having any operation there.
Hope I understand your question correctly 使用Spring / Hibernate,应如何完成这个简单的业务逻辑?

答案3

得分: 0

正如Dexter所说,将所有交易ID存储在Account类中效率低下。让Transaction类成为拥有方,使用账户ID引用Account会更好。

然后,通过使用TransactionRepository,你可以让Spring为你完成工作,通过创建一个简单的查询,找到特定年份内的所有交易,并按账户ID对其进行分组,以找到你的年度现金流。

英文:

As Dexter said, it's inefficient to store all the transaction ids in the Account class. It would be better for the Transaction class to be the owning side and reference the Account using account id.

Then, using a TransactionRepository, you can let Spring do the work for you by creating a simple query that finds all transactions in a given year and group this by account ids to find your yearly cashflow.

huangapple
  • 本文由 发表于 2020年8月18日 13:59:25
  • 转载请务必保留本文链接:https://go.coder-hub.com/63462691.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定