使用 RDBMS 的面向对象方法
我有一个关于在使用 RDBMS（例如 mysql）时如何使用面向对象方法的问题。我正在开发一个小型应用程序来跟踪计费。它是用java构建的，我使用MySQL数据库来存储数据。我的应用程序有一个客户和一个产品类别。现在，通常情况下，如果我使用数组或不同的数据容器处理持久数据存储，我将为客户类和产品类进行更新、删除等操作。然而，我发现自己使用比以往更多的静态方法。因为我没有客户数组，例如我只有一个包含客户信息的数据库，所以当我可以调用删除基于客户（或产品）的静态方法时，我认为创建客户对象只是为了删除它没有意义在它的主要 ID 上。最后，我觉得甚至没有理由创建客户或产品类，因为不需要特定的方法。
我想问大家的是，在使用RDBMS时，如何采用面向对象的方法？
I have a question regarding how to use an object oriented approach while using an RDBMS such as mysql. I am developing a small application that will keep track of billing. It is built in java and I am using a MySQL database to store data. My application has a costumer and a product class. Now normally if I were dealing with persistent data storage using arrays or different data containers I would have an update, delete etc for the customer class and one for the product class. However I find my self using more static methods than ever before. Because I don't have a array of customer for example I just have a database with customers info I see no point in creating a customer object just to delete it when I could just call a static method that deletes a customer (or product) based on it's primary id. In the end I feel like there is no reason to even create a customer or product class because there is no need for specific methods.
What I would like to ask everyone is how do you take an object oriented approach when using a RDBMS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
使用 OO 原则设计您的 Java 类。
使用 SQL 和规范化原则设计数据库。
然后，全速迎接对象/关系映射的挑战！ :-)
像 Hibernate 和 Ibatis 这样的技术是专门为帮助解决这个问题而设计的，这是一个有据可查的问题。像 Spring 这样的附加技术可以使它们的使用变得非常简单和愉快。
将您的持久性抽象为 DAO（数据访问对象）层，例如，如果您有很多像 Vehicle 和 Animal 这样的类，那么您将拥有像 VehicleDao 和 AnimalDao 这样的 DAO，以将它们与数据库的通信方式与它们的基本功能区分开来。你的系统。
FWIW，我主张这样做：在应用程序端进行良好的应用程序设计，在数据端进行良好的数据库设计。完成此操作后，在将类数据持久保存到数据库或从数据库检索类数据时，总有一种方法可以映射这两者，在我看来，这比损害其中一个层来“帮助”另一个层要好得多。
Design your Java classes using OO principles.
Design your DB with SQL and normalisation principles.
Then, run full speed into the challenge that is Object/Relational Mapping! :-)
Technologies like Hibernate and Ibatis are designed specifically to help with this, it's a well documented problem. Additional technologies like Spring can make their use really quite easy and pleasant to work with.
Abstract your persistence to a DAO (Data Access Object) layer, e.g. if you've got lots of classes like Vehicle and Animal, you would have DAOs like VehicleDao and AnimalDao to separate out how they talk to the DB from what they fundamentally do in your system.
FWIW, I advocate doing just this: good app design on the app side, good DB design on the data side. With that done, there's always a way to map the two when persisting and retrieving class data to and from the DB, and that's far better IMO than compromising one of your individual layers to "help" the other.
使用 DTO（数据传输对象）（在您的情况下是代表数据库中对象的类）遵守单一职责原则。这是一种基于 OOP 原则（更具体地说是封装过程）的设计模式。这可确保您的每个类仅实现一个目的。如果将业务逻辑保留在 SQL 字符串中，它将变得难以维护，并且违反了 DRY“不要重复自己”原则。根据我的经验，ORM 加快了系统设计的过程。尝试 NHibernate。 http://geekswithblogs.net/pariam/archive/2006/07/26 /86352.aspx
Using DTO's (Data Transfer Objects), which in your case would be classes that represent the objects in the database, abides by the Single-Responsibility Principle. Which is a design pattern based off of OOP principles (more specifically the process of encapsulation). This ensures that each of your classes accomplishes only one purpose. If you keep your business logic inside SQL strings it becomes hard to maintain and violates the DRY "Don't Repeat Yourself" principle. From my experience ORM's have expedited the process of system design. Try NHibernate. http://geekswithblogs.net/pariam/archive/2006/07/26/86352.aspx
如果您预计该应用程序会不断增长（这可能是 99% 的应用程序），则创建对象。即使删除是单个 SQL 调用，您也可能需要添加逻辑（删除子表中的行、存储审计数据、转向逻辑删除而不是硬删除等）
If you expect this application to ever grow (which is probably 99% of applications) then create the objects. Even if the delete is a single SQL call, down the road you might need to add in logic (delete rows in children tables, store audit data, you move to logical deletes instead of hard deletes, etc.)
您的数据库代表您的业务对象 - 完全规范化等。
您的对象模型代表您需要如何处理代码中的数据。它们通常不相同，例如，您有一个与地址表一对多链接的客户表，但在代码中您使用包含这两种类型信息的对象。
您的数据访问对象 (DAO) 处理业务对象（即读/写）。您的服务层完成工作，如有必要，将 DAO 的输出组合到您的对象中。您的服务层也将根据需要处理事务。
从服务层抽象数据访问将使维护代码、更新数据库模式和促进测试变得更加容易。
Your database represents your business objects - fully normalized, etc.
Your object model represents how you need to work with the data in your code. They are usually not the same, e.g., you have a customer table linked one-to-many to an address table, but in code you use an object that contains both types of information.
Your Data Access Objects (DAOs) handle the business objects (i.e. read/write). Your service layer gets the work done, combining the output of the DAOs into your objects if necessary. Your service layer will handle transactions too as needed.
Abstracting your data access from your service layer will make it easier to maintain code, update the database schema, and facilitate testing.
处理数据库和 oo 代码始终是一个热门话题。有些人可能会说 “只是不要”。
我不同意这些，但当我不得不这样做时，我看到了很多问题。我绝对不同意其他一些立即推荐 OR-Mappers（例如 Hibernate）的观点。在许多情况下，您在开发过程中并没有真正获得任何好处，并且在运行时遇到很多问题（性能、错误诊断）。
一如既往，这一切都取决于您在应用程序中所做的事情。你说，你没有客户对象。这是为什么呢？例如，如果您只是在 gui 内的表中显示所有客户，并且用户可以通过右键单击或其他方式删除其中一个，那么最好的方法是通过 JDBC 读取数据库数据，将其放入您的 JTable 中并拥有一个再次使用JDBC静态删除方法。
但是，如果您确实在应用程序内与客户打交道，那么建立客户对象将会很有用，然后您需要 OR 映射。但你不需要框架。在大多数情况下，手写 sql/JDBC 效果很好。
从我的角度来看，OR-Mapper-Frameworks 在性能不重要并且你没有心情考虑所有数据库内容（即原型设计）的应用程序中可能是一件好事，在大多数其他情况下我会去具有用于读取和存储的手写代码。
Dealing with databases AND oo-code is always a hot topic. And some might say "JUST DON'T".
I don't agree with those, but I've seen a lot problems when I had to do so. I absolutely disagree with some of the others that immediately recommend OR-Mappers like Hibernate. In many cases you don't really have any benefits during development and gain a lot problems (performance, error diagnostics) during runtime.
As always it all depends of what you're doing in your app. You say, you don't have an customer object. Why is this? For example, if you just show all customers in a table inside the gui and the user can delete one of these by right-clicking or whatever, the best approach would be to read DB data via JDBC, put it into your JTable and having a static delete method using JDBC again.
But if you really deal with customers inside the app it will be useful to establish a customer object and then you need OR-Mapping. But you don't need a framework. Handwritten sql/JDBC does a great job in most cases.
From my point of view OR-Mapper-Frameworks can be a good thing in applications where performance isn't interesting and you're not in the mood for thinking about all that DB stuff (i.e. prototyping) in most other cases I'd go with handwritten code for reading and storing.
域模型是一个很好的方法。将您的业务逻辑分离到不直接依赖于数据库的层中。使用 SOLID 原则并查看领域驱动设计。这样，您将拥有可读的、独立的、易于测试的面向对象代码。像“存储库”这样的模式将帮助您在处理关系数据库的实际情况时始终关注业务需求。本质上，您定义和接口如下：
然后在数据访问层（在您的域之外）实现该接口。最简单的方法是使用像 Hibernate 这样的 ORM。数据库在这个架构中的作用更多的是“比特桶”。换句话说，大多数逻辑都存在于面向对象代码中，而数据库只是防止数据异常并加快速度（使用规范化、引用完整性和索引）。
Domain model is good approach. Separate your business logic into a layer that does not depend on database directly. Use SOLID principles and look at Domain Driven Design. This way you will have readable OO code that is isolated and can be easily tested. Patterns like 'Repository' will help you keep focus on business requirements while working with realities of relational database. Essentially you define and interface like:
And then implement this interface in the data access layer (outside your domain). The easiest way is to use ORM like Hibernate. The role of the database in this architecture is more of a 'bit bucket'. In other words, most logic lives in OO code and database just protects against data anomalies and speeds things up (using normalization, referential integrity and indexes).