Spring Data and MongoDB: uncoordinated Design

MongoDB is a well-known NoSQL document database, while Spring is a well-known open-source framework in the Java field. In addition to the IoC and AOP components that constitute the core of Spring, Spring also has a large number of sub-frameworks applied in different fields. Spring Data is a sub-project dedicated to Data processing. In Spring Data, there are sub-projects such as Spring Data JPA, Spring Data MongoDB, and Spring Data Redis. The target of these sub-projects can be identified by their names. Among them, Spring Data MongoDB is a subproject dedicated to MongoDB and is designed to manipulate MongoDB through Spring. Does this integration simplify development or impede development? Prashant Deva is the founder and CTO of Chronon. He is a continuous entrepreneur and also founded Placid Systems, antlstudio and Virtual Ant. As a geek, Deva prefers to try a variety of new technologies. After using Spring Data MongoDB for a while, he believes that this framework has serious problems in design, I wrote an article for in-depth and detailed analysis. Spring framework developers like to promote their support for MongoDB and use it as a capital better than other frameworks. However, if you use Spring Data MongoDB in a real project, you will find that the framework has serious defects in some features and huge design mistakes. Spring Data MongoDB tries to hard plug the ORM-style architecture into non-relational databases, which directly causes serious consequences that cannot be used in actual projects. The following describes the reasons behind this: fields cannot be retrieved. You can only obtain the entire document. This is the biggest flaw in the design of Spring Data MongoDB. It tries to use rows in the SQL database to model the document and wants you to create an "entity" class like an ORM. The two are not the same at all. The documentation is much more complicated than the rows in the SQL database. For rows in the SQL database, it thinks that you will obtain all the data in most queries, otherwise the data should be divided into multiple tables. However, documents are completely different. documents can be nested. In many cases, you only need to obtain a subset of documents from the database. However, for the "entity" model of Spring Data MongoDB, You have to retrieve the entire document in each query. It's even more crazy to load without DBRef delay. If you reference other documents through DBRefs, Spring Data MongoDB will get the entire document instead of the document reference. If a large number of documents are connected through DBRefs, a simple query that only obtains several fields will result in obtaining the entire document graph! The actual situation is that this Bug report has been in the "low priority" status for nearly two years, and there is no solution, which is incredible, this shows how big a gap exists between the vision of Spring Data MongoDB and its actual use. Does the cursor not support traversing the set through the cursor? No. You can either retrieve the entire set or use the native Mongo Java driver. The incomplete aggregation framework supports Spring Data MongoDB from a short time ago. Just like other parts of the framework, such support is also a semi-finished product. The framework documentation is rare and confusing. Most of the aggregate queries required in the actual project cannot be found in the Spring Data MongoDB documentation. You can only use the native driver. Although incomplete indexing support can mark a field as "indexed" through the framework, other operations do not know about this. Take an example in MongoDB. If a field is unique and sparse, you cannot use the null value to insert more than once to the document. This means that the field should not appear at the position of the 2nd insert operation. However, since Spring forces you to define the fields in the document in a class, you must finally assign null to a non-existent field. If this field has a unique sparse index, this will cause a runtime error, because Spring creates a query based on the object (defined directly on the field in the form of annotations ), it does not know the existence of indexes at all. Spring also provides an ensureIndex () method for manually creating indexes on fields without annotations. However, the document does not mention the time to use this method and how often it is used, and the call performance. You can't switch databases. In many cases, you want to store data in different databases of a single MongoDB instance. For example, you need to keep the data of different customers separated. If you use the native Mongo driver, switching to a database is simply a piece of cake, just call getDb (dbName. However, if Spring Data MongoDb is used, this is almost impossible, unless you are willing to write a lot of code on your own (but this may cause portability problems after the new framework is released ). I have already written a special article on Spring documentation. The Spring document says that it uses Jakarta Commons Logging, but Spring Data apparently uses SLF4J. However, this is not mentioned in the Spring Data document. This means that if you start to use Spring Data, you may encounter runtime errors that are not mentioned in many documents. There is no other way at this time. Go to StackOverflow to find the answer. The biggest reason why documents-oriented databases such as MongoDB are not supported for their dynamic features is their dynamic features. For example, the documents in the same set can be different, so that the same set can have documents of multiple versions, and then gradually upgrade and the documents can also be nested. You do not need to know the key name in advance, so that you can directly Insert the property ing to the document. However, the fact is that Spring Data MongoDB discards this basic feature of MongoDB and tries to build a definite, pre-defined ORM-Style Layer on it, this directly causes the mismatch between the framework and the underlying database. Conclusion Spring Data MongoDB seems to have been designed by some people who haven't used MongoDB in real projects. It tries to hard plug the document-oriented database into the ORM-style framework. This leads to the mismatch between the framework and the database. Spring Data MongoDB has become a burden rather than helping us simplify development. Finally, you still have to use the native MongoDB Java driver in almost all real project development. Note: Have you ever used Spring Data MongoDB for MongoDB development? How do you feel about Spring Data MongoDB? Is it consistent with Deva's experience? I once tried Spring Data MongoDB in the project. The intuitive feeling of using it is that it makes simple things complicated. Directly Using the native Java driver to manipulate MongoDB is a very simple and intuitive process, while Spring Data MongoDB adopts its processing style, that is, IoC, which requires injection first, then, retrieve the required objects from the container and make the originally easy operation complicated. I don't know how readers feel. You are welcome to discuss this.