与 Java 中的数据表作斗争
我是一名 .NET 开发人员，正在尝试使用 Java。我当前的项目有 UI 层、业务逻辑层和数据访问层。我目前正在 DAL 工作。
我还没有连接到外部数据库；我曾希望让我的 DAL 类利用内存中的数据表，直到数据库就位。
在 .NET 中，创建内存数据表、从中选择、添加到其中以及从中删除非常容易。但是，在 Java 中，我一直无法找到做同样事情的东西。
我正在考虑用强类型对象的集合替换“dataTables”；但这需要在 DAL 内部添加对业务层的引用（我认为这是一个禁忌）。
有人可以帮助困惑的开发人员吗？如果整个方法有缺陷，你会怎么做？如果我错过了 Java 中 dataTable 的等价物 - 它是什么？
I'm a .NET Developer trying my hand at Java. My current project has a UI layer, Business logic layer, and a Data Access layer. I'm currently working on the DAL.
I'm not connecting to an external database yet; I had hoped to have my DAL classes utilize in-memory dataTables until the DB is in place.
In .NET it's very easy to make in-memory dataTables, select from them, add to them, and remove from them. But, in Java, I've been unable to find something that does the same thing.
I was considering replacing the 'dataTables' with a collection of strongly typed objects; but that would require adding references to Business layer inside of the DAL (and I thought that was a no-no).
Can someone help a confused developer out? If this whole approach is flawed, what would you do? If I missed the equivalent of a dataTable in Java - what is it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是一篇文章 关于运行内存中 Derby 数据库。
如果我知道您正在使用什么数据库和持久性库，我也许能够给出更准确的答案。
Here's an article on running an in-memory Derby database.
If I knew what database and what persistence library you're using, I might be able to give a more precise answer.
您可以使用 这个答案。
这个 SO 问题中显示了不同内存数据库的比较。
You could use a memory database like described in this answer.
A comparison of different memory databases is shown in this SO question.
这些规则是谁制定的？
如果您的数据访问层负责模型对象的 CRUD 操作，那么在我看来，它必须引用它们。没有办法解决这个问题。
持久层不需要了解服务层或视图层。
唯一完全解耦的类是不与任何人交谈且不提供任何内容的类。没用的。
不要太执着于“规则”。您正在尝试对您的应用程序进行分层。您将有关持久性的所有内容放入类层中。
我不认为内存数据库对设计持久层的方式有任何影响。您应该能够交换关系数据库或平面文件或任何其他机制，但界面不应更改。这是一个实现细节。
Who makes up these rules?
If your data access layer is responsible for CRUD operations for model objects, it seems to me that it has to have references to them. There's no way around that.
The persistence tier need not know about the service or view layers.
The only completely uncoupled class is one that talks to no one and offers nothing. It's useless.
Don't be so hung up on "rules". You're trying to layer your application. You're putting all things about persistence into a layer of classes.
I don't think in-memory database has any effect on the way you design the persistence tier. You should be able to swap in a relational database or flat file or any other mechanism, but the interface shouldn't change. That's an implementation detail.
OR/M 在 Java 中的出现比在 .NET 中要早得多。数据集有缺陷，因为它们迫使您按程序进行编程。尝试与对象交互并稍后将它们映射到数据库。
OR/Ms were available much earlier in Java than in .NET. DataSets are flawed in that they force you to program procedurally. Try to interact with objects and map those to the DB later.