从数据库中获取数据的最 DRY 方法是什么？
我必须编写一个 ASP.NET 应用程序来连接到我们遗留的 IBM Universe 数据库，并且我们正在使用名为 mv.net 的产品，它允许我们连接、读取、写入、选择、运行服务器端程序等。
我想要的尽可能少代码重复尽可能多，但我也希望数据传输尽可能少。
为了打开连接，我们必须首先使用以下代码获取对帐户的引用：
mvAccount myAccount = new mvAccount(serverName, login);
然后我们可以读取一个项目：
mvFile myInvoiceFile = myAccount.FileOpen("INVOICE");
mvItem myInvoiceRecord = myInvoiceFile.Read(invoiceID);
然后我们就完成了：
myAccount.Logout();
我为每个模块都有一个类，所以我可能有发票、采购订单、 RMA、请求、装运等。 在 INVOICE 中，我可能需要访问多个表，例如 CUSTOMER、INVOICE、TERMS、SHIPVIA 等。
我计划做的是创建一个名为 TechDB 的类，这是我们数据库的名称，并将代码放在其中，以便在我的 INVOICE 中我只能说：
TechDB connection = new TechDB();
mvItem myInvoiceRecord = connection.Read("INVOICE", invoiceID)
当我这样做时，我的 TechDB 类将打开连接，读取记录，然后一步注销。
我认为我正走在正确的道路上，但如果不是，请告诉我。 以下是我的问题：
如何在我的 INVOICE 类中返回错误？ 例如，如果我们无法连接数据库、无法打开文件、无法读取记录，则可能会发生错误。
如果我需要从 INVOICE 中获取一些数据，然后读取 TERMS 表，该怎么办？ 我不想在刚打开数据库时就必须打开一个新的数据库连接。
我应该在所有具有该方法的类上调用 Dispose 方法吗？ 例如，mvAccount 有一个 Dispose 方法。 没有文档说要调用它，但是我应该在 Logout() 之后调用它吗？
我可以在 TechDB 类上创建一个执行 myAccount.Logout() 的 Dispose 方法吗？ 这样连接将保持打开状态，当我完全完成它时，我可以从我的 INVOICE 类中关闭它？
给我一些关于处理这个问题的最佳方法的意见吗？ 我的目标是一个强大的应用程序，易于修改并且代码重复尽可能少。
I have to write an ASP.NET application that connects to our legacy IBM Universe Database and we are using a product called mv.net which allows us to connect, read, write, select, run server side programs, etc.
I want as little code repetition as possible but I also want as little data transfer as possible as well.
In order to open a connection we must first get a reference to the account using code such as:
mvAccount myAccount = new mvAccount(serverName, login);
Then we can read an item:
mvFile myInvoiceFile = myAccount.FileOpen("INVOICE");
mvItem myInvoiceRecord = myInvoiceFile.Read(invoiceID);
Then we we're done:
myAccount.Logout();
I have a Class for each module, so I may have INVOICE, PURCHASE_ORDER, RMA, REQ, SHIPMENT, and so on. Within INVOICE, I may need to access multiple tables such as CUSTOMER, INVOICE, TERMS, SHIPVIA, etc.
What I planned to do was create a class called TechDB which is the name of our database and put the code in there so in my INVOICE class I can just say:
TechDB connection = new TechDB();
mvItem myInvoiceRecord = connection.Read("INVOICE", invoiceID)
When I do this my TechDB class would open the connection, read the record, and then logout all in one step.
I think I'm heading down the right path but please let me know if not. Here are my problems with this:
How do I return errors my INVOICE class? For example, errors could occur if we are unable to connect to the database, unable to open the file, unable to read the record.
What if I then need to take some data from my INVOICE and then read the TERMS table. I'd hate to have to open a new connection to the database when I just opened one.
Should I call the Dispose method on all classes that have this? For example, the mvAccount has a Dispose method. None of the documentation says to call it, but should I after the Logout()?
Could I create a Dispose method on the TechDB class that does the myAccount.Logout()? That way the connection would remain open and I could close it from my INVOICE class when I was completely done with it?
Give me some opinions on the best way to handle this? My goal is a robust application that is easy to modify and as little code repitition as possible.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会使用闭包，我认为对于 C# 你有委托。 就像这样：
MyAccount.loginAndDo(servername, login, delegate(account){ invoice = account.read("INVOICE"); . . . });在 loginAndDo 中，您将登录，调用委托，然后关闭帐户。
I would use closures, I think for C# you have Delegates. So something like:
MyAccount.loginAndDo(servername, login, delegate(account){ invoice = account.read("INVOICE"); . . . });In loginAndDo, you would login, call the delegate, and then close the account.
按照 3/4。 就我而言，所有数据访问对象都继承自一个包含对连接的静态引用的类。 我对在 Dispose 中实现断开连接逻辑犹豫不决，因为可能会出现断电或系统崩溃或其他情况并且连接未释放。
as per 3/4. In my case, all of my data access objects inherit from a class that holds a static reference to a connection. I'm hesitant to implement disconnect logic in Dispose because of the possibility that there is a power out or system crash or something and that connection isn't released.