1. Advantages
Simple:
Easy to learn, easy to use, through the documentation and source code, you can compare the complete grasp of its design ideas and implementation.
Practical:
Provides data mapping capabilities, provides encapsulation of underlying data access (such as ADO), provides a DAO framework that makes it easier for us to develop and configure our DAL layer. Flexible:
With SQL you can basically implement all the features that we can do without using the data access framework, perhaps more. Full function:
Provides connection management, caching support, threading support, (distributed) things management, and the issues that need to be addressed by configuring data access layers such as relational object mappings. DAO support is provided and ado.net,nhibernate and Datamapper are encapsulated in the DAO framework. Enhanced maintainability of the system:
By providing a DAL layer that separates business logic from data access logic, the system is designed to be clearer, easier to maintain, and easier to unit test. The separation of SQL and code improves maintainability.
2. Disadvantages
Lag:
There's no definite right. NET2.0 's support. The latest version can be compiled under 2.0, but some unit tests do not pass.
Immature, less engineering practice:
Ibatisnet is less used in actual projects. Only theoretically feasible.
Semi-ORM with less tool support:
We need to write our own SQL, and. NET has not found a tool that can automatically generate business layer classes and configuration files, this is not the same as NHibernate, NHibernate will directly generate SQL for our database, and there are some ancillary tools. So use Ibatis to do more work than nhibernate.
3. Feasibility
There is no best frame, only the most suitable frame. The existence is reasonable, it exists to show that there is a reason for its existence. But it does not necessarily exist for us. So the most important thing to choose a framework is to see if it has any meaning to you, how much it means, and whether it is more beneficial than other frameworks. There is no absolute advantage and no absolute disadvantage, it is important to see under what circumstances to discuss. It says some of the pros and cons of some of the ibatis. These advantages theoretically prove that Ibatis is suitable for any data persistence layer, but not necessarily the best choice. The advantages and disadvantages of the above are discussed from two aspects respectively. Simple: We all like simplicity, simplicity means low learning costs and low likelihood of errors in use. At the same time, simple things are generally not powerful enough. In turn, complex things to learn the cost of high, inconvenient to use, and the team does not have a strong technical strength, generally do not use. Practical:
Solves the problem that needs to be solved in the project, this is the nature which the frame and the tool should have in any actual project, otherwise do not get the actual project. Flexible: Flexible with two levels of meaning, one is simple and easy to expand, the other is powerful provides a lot of options. Ibatis belongs to the former and hibernate belongs to the latter. Both have their advantages and disadvantages. Functional integrity: Ibatis's functional integrity is also relative, more than our own development of the framework should be complete, but compared to other frameworks must also have some unresolved problems. Enhanced maintainability of the system: SQL and code separation can be done using Ibatis, which enables a clear data access layer (DAL) to be designed. But the project structure is scientific and reasonable, whether to maintain, the key is not ibatis, because it is only a data layer framework. But we also have to be clear that in order to take advantage of the ibatis, we need to do some extra work, such as the best design of the DAO interface, the need to put business layer entities and access to entities in different projects, and the need to maintain XML configuration files. Hysteresis: The Ibatis group is not yet mentioned to support. NET2.0, a lot of people have problems using ibatis under. NET2.0. So if you want to use. NET2.0 Development, Ibatis is not a good choice, still need to wait. Immature: Open source things are hard to say, but generally more mature than the framework we write ourselves. Since we can get his source code, the key is whether we are able to harness it. Semi-ORM, less tool support: This is doomed ibatis can not improve the efficiency of development in nature, we need to write their own SQL, realistic body class, write configuration files. But this is also its superior place, it does not do for us many of him, so we have more to cast space. It is ideal for systems that do not have full control of the database and for the development of statistical query systems that need to take advantage of the advanced features provided by the database itself.
Using Ibatis requires you to write your own SQL, because our SQL cannot fully conform to the SQL standard, compared to the SQL generated by NHibernate, the portability is poor. However, since we are less likely to change the database, it is not necessary for us to meet the criteria for SQL compliance so that the price can be minimized when migrating to different servers. On the other hand, although nhibernate can block the differences between many databases, it is difficult to take advantage of the advanced features of some databases, such as Oracle's analytic statistics functions.
NHibernate is not suitable for the database schema is not standardized, the constraints are incomplete, requires a large number of complex query system, at the same time NHibernate learning cost is higher, fully grasp the nhibernate is more difficult, the risk is greater. Writing a frame yourself is not necessarily better, stable, powerful, and extensible than Ibatis. and the development of their own framework also requires a larger workload. If you use dotnet and want to choose a data-layer framework, and the system has a considerable number of more complex SQL, or database design is unreasonable, dirty data, performance and resource requirements are strict, ibatis is a good choice. His shortcomings are not lethal, and there are some solutions. In particular, when the Ibatis DataAccess is elected as the DAO framework, we can use the Nhibernate,ado at the same time. NET and Datamapper (core components of ibatisnet), that will minimize risk and the overall system framework is reasonable.
In addition, the use of Ibatis can unify the coding style, save development costs, we will not waste to the paging connection pool primary key generation, etc., you can focus on the business components of the writing.
Comprehensive:
There are many times when we need to take a holistic look at the framework issues that are our own development framework and the selection of third-party frameworks and frameworks. The criteria to be considered are, of course, the current situation of the project and a balance that we want to achieve.
Ibatis just encapsulates the data access layer and makes a partial object-relational mapping for us. But our price is that we have to write an XML configuration file, and we write a lot of SQL relative to hibernate. Hibernate generates entity classes and basic configuration files directly from the database schema using the tool, and in most cases does not require us to write SQL, which can greatly improve the development efficiency. But these also have a lot of limitations, especially the environmental requirements (database design, object design, teamwork, etc.). Personal feeling Ibatis What's interesting about the project is that it's small, flexible, extensible, encapsulates the data access layer (transactions, caches, exceptions, logs), and provides support for the DAO framework.
With Ibatis we can do the separation of code and SQL, as long as the SQL can solve the problem, Ibatis can help us easier to solve, but also make our project to a framework of the dependence of small (because Ibatis is non-invasive). This will greatly reduce the project risk, reduce the time to solve complex problems, make the maintenance of the project easier.
Ibatis the modification, commissioning, expansion and maintenance of the application will become easy and natural. When we modify, we mainly modify the entity object that represents the model, the SQL in the XML configuration file, and/or the resultmap of the configuration file (many times it is not needed). At the same time, with SQL and code separation, we don't have to look for the SQL that needs to be modified between the StringBuffer append methods of the code. The SQL in the configuration file facilitates our debugging and review of SQL and subsequent SQL reuse.
Using some frameworks in the early stages generally slows down development efficiency. Because we need to pay the cost of learning, many times, the use of frameworks need to write a lot of configuration files, when the use of non-mature development speed is slow, while the use of the framework tends to increase the amount of system code, such as Model1 and MODEL2 model, development efficiency should be Model1 fast, The four-tier architecture is certainly larger than the two-tier code. But for the middle and later development and maintenance will greatly improve the efficiency.
Using some of the more complete development framework and code generation tools will greatly improve the development efficiency in the early stage, but it will often slow down the progress at a later stage and may become a nightmare for future maintenance. For example, torque generated entity classes and their corresponding SQL, although greatly improved efficiency, but the burden of modification is large.
The ideal way to develop is to use simple frameworks combined with simple code generation tools. The framework provides the basic services of the system and regulates development. On the one hand, the framework provides development-based support for a particular aspect of development, such as data access layers, transactions, logs, common classes, exceptions, and so on. On the other hand, the model is defined for development, and the basic contour of the system is defined. At the same time, some low-level code is generated through a simple code generation tool. For example, an entity class is generated from a database schema using a tool. After these classes are generated, we are free to modify them.
Hibernate is a very powerful, well-developed ORM framework, but it has its advantages and disadvantages. The use of Hibernate3 in the Java EE system is an issue that needs careful evaluation.
For hibernate to work well, the database must be designed well. It is acceptable to use SQL,HIBERNATE3 for complex data operations at the same time, which is more natural than Hibernate2 for direct SQL support.
Hibernate is complex, powerful and flexible, and it's not really easy to use hibernate, but the Spring framework provides a package for hibernate, making hibernate easier to use. Ibatis can be said to be applicable in any system, but not necessarily the best choice. But the idea that Ibatis provides is that we should think about it carefully.
Advantages and disadvantages of ibatis and feasibility analysis
