Generic Data Access Objects [转]
The DAO interfaces An implementation with Hibernate Preparing DAOs with factories Preparing DAOs with manual dependency injection Preparing DAOs with lookup Writing DAOs as managed EJB 3.0 components A Better typed Generic DAO? You decide!
- The DAO interfaces
- An implementation with Hibernate
- Preparing DAOs with factories
- Preparing DAOs with manual dependency injection
- Preparing DAOs with lookup
- Writing DAOs as managed EJB 3.0 components
- A Better typed Generic DAO? You decide!
This is a pattern for Data Access Objects with JDK 5.0, from the CaveatEmptor example application. It is also explained in the book Java Persistence with Hibernate. Two links you might find useful: Sessions and transactions and Open Session in View.
This time I based the DAO example on interfaces. Tools like Hibernate already provide database portability, so persistence layer portability shouldn't be a driving motivation for interfaces. However, DAO interfaces make sense in more complex applications, when several persistence services are encapsulate in one persistence layer. I'd say that you should use Hibernate (or Java Persistence APIs) directly in most cases, the best reason to use an additional DAO layer is higher abstraction (e.g. methods like getMaximumBid()instead of session.createQuery(...) repeated a dozen times).
The DAO interfaces
I use one interface per persistent entity, with a super interface for common CRUD functionality:
<code><span><strong>public</strong></span> <span><strong>interface</strong></span> GenericDAO<t id><strong>extends</strong> Serializable> <span>{</span> T findById(ID id, <span><strong>boolean</strong></span> lock); List<t> findAll(); List<t> findByExample(T exampleInstance); T makePersistent(T entity); <span><strong>void</strong></span> makeTransient(T entity); <span>}</span> </t></t></t></code>
You can already see that this is going to be a pattern for a state-oriented data access API, with methods such as makePersistent() and makeTransient(). Furthermore, to implement a DAO you have to provide a type and an identifier argument. As for most ORM solutions, identifier types have to be serializable.
The DAO interface for a particular entity extends the generic interface and provides the type arguments:
<code><span><strong>public</strong></span> <span><strong>interface</strong></span> ItemDAO <span><strong>extends</strong></span> GenericDAO<item long> <span>{</span> <span><strong>public</strong></span> <span><strong>static</strong></span> <span><strong>final</strong></span> String QUERY_MAXBID = <span>"ItemDAO.QUERY_MAXBID"</span>; <span><strong>public</strong></span> <span><strong>static</strong></span> <span><strong>final</strong></span> String QUERY_MINBID = <span>"ItemDAO.QUERY_MINBID"</span>; Bid getMaxBid(Long itemId); Bid getMinBid(Long itemId); <span>}</span> </item></code>
We basically separate generic CRUD operations and actual business-related data access operations from each other. (Ignore the named query constants for now, they are convenient if you use annotations.) However, even if only CRUD operations are needed for a particular entity, you should still write an interface for it, even it it is going to be empty. It is important to use a concrete DAO in your controller code, otherwise you will face some refactoring once you have to introduce specific data access operations for this entity.
An implementation with Hibernate
An implementation of the interfaces could be done with any state-management capable persistence service. First, the generic CRUD implementation with Hibernate:
<code><span><strong>public</strong></span> <span><strong>abstract</strong></span> <span><strong>class</strong></span> GenericHibernateDAO<t id><strong>extends</strong> Serializable> <span><strong>implements</strong></span> GenericDAO<t id> <span>{</span> <span><strong>private</strong></span> Class<t> persistentClass; <span><strong>private</strong></span> Session session; <span><strong>public</strong></span> GenericHibernateDAO() <span>{</span> this.persistentClass = (Class<t>) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0]; <span>}</span> @SuppressWarnings(<span>"unchecked"</span>) <span><strong>public</strong></span> <span><strong>void</strong></span> setSession(Session s) <span>{</span> this.session = s; <span>}</span> <span><strong>protected</strong></span> Session getSession() <span>{</span> <span><strong>if</strong></span> (session == <span><strong>null</strong></span>) <span><strong>throw</strong></span> <span><strong>new</strong></span> IllegalStateException(<span>"Session has not been set on DAO before usage"</span>); <span><strong>return</strong></span> session; <span>}</span> <span><strong>public</strong></span> Class<t> getPersistentClass() <span>{</span> <span><strong>return</strong></span> persistentClass; <span>}</span> @SuppressWarnings(<span>"unchecked"</span>) <span><strong>public</strong></span> T findById(ID id, <span><strong>boolean</strong></span> lock) <span>{</span> T entity; <span><strong>if</strong></span> (lock) entity = (T) getSession().load(getPersistentClass(), id, LockMode.UPGRADE); <span><strong>else</strong></span> entity = (T) getSession().load(getPersistentClass(), id); <span><strong>return</strong></span> entity; <span>}</span> @SuppressWarnings(<span>"unchecked"</span>) <span><strong>public</strong></span> List<t> findAll() <span>{</span> <span><strong>return</strong></span> findByCriteria(); <span>}</span> @SuppressWarnings(<span>"unchecked"</span>) <span><strong>public</strong></span> List<t> findByExample(T exampleInstance, String[] excludeProperty) <span>{</span> Criteria crit = getSession().createCriteria(getPersistentClass()); Example example = Example.create(exampleInstance); <span><strong>for</strong></span> (String exclude : excludeProperty) <span>{</span> example.excludeProperty(exclude); <span>}</span> crit.add(example); <span><strong>return</strong></span> crit.list(); <span>}</span> @SuppressWarnings(<span>"unchecked"</span>) <span><strong>public</strong></span> T makePersistent(T entity) <span>{</span> getSession().saveOrUpdate(entity); <span><strong>return</strong></span> entity; <span>}</span> <span><strong>public</strong></span> <span><strong>void</strong></span> makeTransient(T entity) <span>{</span> getSession().delete(entity); <span>}</span> <span><strong>public</strong></span> <span><strong>void</strong></span> flush() <span>{</span> getSession().flush(); <span>}</span> <span><strong>public</strong></span> <span><strong>void</strong></span> clear() <span>{</span> getSession().clear(); <span>}</span> <span>/** * Use this inside subclasses as a convenience method. */</span> @SuppressWarnings(<span>"unchecked"</span>) <span><strong>protected</strong></span> List<t> findByCriteria(Criterion... criterion) <span>{</span> Criteria crit = getSession().createCriteria(getPersistentClass()); <span><strong>for</strong></span> (Criterion c : criterion) <span>{</span> crit.add(c); <span>}</span> <span><strong>return</strong></span> crit.list(); <span>}</span> <span>}</span> </t></t></t></t></t></t></t></t></code>
There are some interesting things in this implementation. First, it clearly needs a Session to work, provided with setter injection. You could also use constructor injection. How you set the Session and what scope this Session has is of no concern to the actual DAO implementation. A DAO should not control transactions or the Session scope.
We need to suppress a few compile-time warnings about unchecked casts, because Hibernate's interfaces are JDK 1.4 only. What follows are the implementations of the generic CRUD operations, quite straightforward. The last method is quite nice, using another JDK 5.0 feature, varargs. It helps us to build Criteria queries in concrete entity DAOs. This is an example of a concrete DAO that extends the generic DAO implementation for Hibernate:
<code><span><strong>public</strong></span> <span><strong>class</strong></span> ItemDAOHibernate extends GenericHibernateDAO<item long> implements ItemDAO <span>{</span> <span><strong>public</strong></span> Bid getMaxBid(Long itemId) <span>{</span> Query q = getSession().getNamedQuery(ItemDAO.QUERY_MAXBID); q.setParameter(<span>"itemid"</span>, itemId); <span><strong>return</strong></span> (Bid) q.uniqueResult(); <span>}</span> <span><strong>public</strong></span> Bid getMinBid(Long itemId) <span>{</span> Query q = getSession().getNamedQuery(ItemDAO.QUERY_MINBID); q.setParameter(<span>"itemid"</span>, itemId); <span><strong>return</strong></span> (Bid) q.uniqueResult(); <span>}</span> <span>}</span> </item></code>
Another example which uses the findByCriteria() method of the superclass with variable arguments:
<code><span><strong>public</strong></span> <span><strong>class</strong></span> CategoryDAOHibernate extends GenericHibernateDAO<category long> implements CategoryDAO <span>{</span> <span><strong>public</strong></span> Collection<category> findAll(<span><strong>boolean</strong></span> onlyRootCategories) <span>{</span> <span><strong>if</strong></span> (onlyRootCategories) <span><strong>return</strong></span> findByCriteria( Expression.isNull(<span>"parent"</span>) ); <span><strong>else</strong></span> <span><strong>return</strong></span> findAll(); <span>}</span> <span>}</span> </category></category></code>
Preparing DAOs with factories
We could bring it all together in a DAO factory, which not only sets the Session when a DAO is constructed but also contains nested classes to implement CRUD-only DAOs with no business-related operations:
<code><span><strong>public</strong></span> <span><strong>class</strong></span> HibernateDAOFactory <span><strong>extends</strong></span> DAOFactory <span>{</span> <span><strong>public</strong></span> ItemDAO getItemDAO() <span>{</span> <span><strong>return</strong></span> (ItemDAO)instantiateDAO(ItemDAOHibernate.class); <span>}</span> <span><strong>public</strong></span> CategoryDAO getCategoryDAO() <span>{</span> <span><strong>return</strong></span> (CategoryDAO)instantiateDAO(CategoryDAOHibernate.class); <span>}</span> <span><strong>public</strong></span> CommentDAO getCommentDAO() <span>{</span> <span><strong>return</strong></span> (CommentDAO)instantiateDAO(CommentDAOHibernate.class); <span>}</span> <span><strong>public</strong></span> ShipmentDAO getShipmentDAO() <span>{</span> <span><strong>return</strong></span> (ShipmentDAO)instantiateDAO(ShipmentDAOHibernate.class); <span>}</span> <span><strong>private</strong></span> GenericHibernateDAO instantiateDAO(Class daoClass) <span>{</span> <span><strong>try</strong></span> <span>{</span> GenericHibernateDAO dao = (GenericHibernateDAO)daoClass.newInstance(); dao.setSession(getCurrentSession()); <span><strong>return</strong></span> dao; <span>}</span> <span><strong>catch</strong></span> (Exception ex) <span>{</span> <span><strong>throw</strong></span> <span><strong>new</strong></span> RuntimeException(<span>"Can not instantiate DAO: "</span> + daoClass, ex); <span>}</span> <span>}</span> <span>// You could override this if you don't want HibernateUtil for lookup</span> <span><strong>protected</strong></span> Session getCurrentSession() <span>{</span> <span><strong>return</strong></span> HibernateUtil.getSessionFactory().getCurrentSession(); <span>}</span> <span>// Inline concrete DAO implementations with no business-related data access methods.</span> <span>// If we use public static nested classes, we can centralize all of them in one source file.</span> <span><strong>public</strong></span> <span><strong>static</strong></span> <span><strong>class</strong></span> CommentDAOHibernate <span><strong>extends</strong></span> GenericHibernateDAO<comment long> <span><strong>implements</strong></span> CommentDAO <span>{</span><span>}</span> <span><strong>public</strong></span> <span><strong>static</strong></span> <span><strong>class</strong></span> ShipmentDAOHibernate <span><strong>extends</strong></span> GenericHibernateDAO<shipment long> <span><strong>implements</strong></span> ShipmentDAO <span>{</span><span>}</span> <span>}</span> </shipment></comment></code>
This concrete factory for Hibernate DAOs extends the abstract factory, which is the interface we'll use in application code:
<code><span><strong>public</strong></span> <span><strong>abstract</strong></span> <span><strong>class</strong></span> DAOFactory <span>{</span> <span>/** * Creates a standalone DAOFactory that returns unmanaged DAO * beans for use in any environment Hibernate has been configured * for. Uses HibernateUtil/SessionFactory and Hibernate context * propagation (CurrentSessionContext), thread-bound or transaction-bound, * and transaction scoped. */</span> <span><strong>public</strong></span> <span><strong>static</strong></span> <span><strong>final</strong></span> Class HIBERNATE = org.hibernate.ce.auction.dao.hibernate.HibernateDAOFactory.class; <span>/** * Factory method for instantiation of concrete factories. */</span> <span><strong>public</strong></span> <span><strong>static</strong></span> DAOFactory instance(Class factory) <span>{</span> <span><strong>try</strong></span> <span>{</span> <span><strong>return</strong></span> (DAOFactory)factory.newInstance(); <span>}</span> <span><strong>catch</strong></span> (Exception ex) <span>{</span> <span><strong>throw</strong></span> <span><strong>new</strong></span> RuntimeException(<span>"Couldn't create DAOFactory: "</span> + factory); <span>}</span> <span>}</span> <span>// Add your DAO interfaces here</span> <span><strong>public</strong></span> <span><strong>abstract</strong></span> ItemDAO getItemDAO(); <span><strong>public</strong></span> <span><strong>abstract</strong></span> CategoryDAO getCategoryDAO(); <span><strong>public</strong></span> <span><strong>abstract</strong></span> CommentDAO getCommentDAO(); <span><strong>public</strong></span> <span><strong>abstract</strong></span> ShipmentDAO getShipmentDAO(); <span>}</span> </code>
Note that this factory example is suitable for persistence layers which are primarily implemented with a single persistence service, such as Hibernate or EJB 3.0 persistence. If you have to mix persistence APIs, for example, Hibernate and plain JDBC, the pattern changes slightly. Keep in mind that you can also call session.connection() inside a Hibernate-specific DAO, or use one of the many bulk operation/SQL support options in Hibernate 3.1 to avoid plain JDBC.
Finally, this is how data access now looks like in controller/command handler code (pick whatever transaction demarcation strategy you like, the DAO code doesn't change):
<code><span>// EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED)</span> <span><strong>public</strong></span> <span><strong>void</strong></span> execute() <span>{</span> <span>// JTA: UserTransaction utx = jndiContext.lookup("UserTransaction");</span> <span>// JTA: utx.begin();</span> <span>// Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction();</span> DAOFactory factory = DAOFactory.instance(DAOFactory.HIBERNATE); ItemDAO itemDAO = factory.getItemDAO(); UserDAO userDAO = factory.getUserDAO(); Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, <span><strong>true</strong></span>); newBid = item.placeBid(userDAO.findById(userId, <span><strong>false</strong></span>), bidAmount, currentMaxBid, currentMinBid); <span>// JTA: utx.commit(); // Don't forget exception handling</span> <span>// Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling</span> <span>}</span> </code>
The database transaction, either JTA or direct JDBC, is started and committed in an interceptor that runs for every execute(), following the Open Session in View pattern. You can use AOP for this or any kind of interceptor that can be wrapped around a method call, see Session handling with AOP.
Preparing DAOs with manual dependency injection
You don't need to write the factories. You can as well just do this:
<code><span>// EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED)</span> <span><strong>public</strong></span> <span><strong>void</strong></span> execute() <span>{</span> <span>// JTA: UserTransaction utx = jndiContext.lookup("UserTransaction");</span> <span>// JTA: utx.begin();</span> <span>// Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction();</span> ItemDAOHibernate itemDAO = <span><strong>new</strong></span> ItemDAOHibernate(); itemDAO.setSession(HibernateUtil.getSessionFactory().getCurrentSession()); UserDAOHibernate userDAO = <span><strong>new</strong></span> UserDAOHibernate(); userDAO.setSession(HibernateUtil.getSessionFactory().getCurrentSession()); Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, <span><strong>true</strong></span>); newBid = item.placeBid(userDAO.findById(userId, <span><strong>false</strong></span>), bidAmount, currentMaxBid, currentMinBid); <span>// JTA: utx.commit(); // Don't forget exception handling</span> <span>// Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling</span> <span>}</span> </code>
The disadvantage here is that the implementation classes (i.e. ItemDAOHibernate and UserDAOHibernate) of the persistence layer are exposed to the client, the controller. Also, constructor injection of the current Session might be more appropriate.
Preparing DAOs with lookup
Alternatively, call HibernateUtil.getSessionFactory().getCurrentSession() as a fallback, if the client didn't provide a Session when the DAO was constructed:
<code><span><strong>public</strong></span> <span><strong>abstract</strong></span> <span><strong>class</strong></span> GenericHibernateDAO<t id><strong>extends</strong> Serializable> <span><strong>implements</strong></span> GenericDAO<t id> <span>{</span> <span><strong>private</strong></span> Class<t> persistentClass; <span><strong>private</strong></span> Session session; <span><strong>public</strong></span> GenericHibernateDAO() <span>{</span> this.persistentClass = (Class<t>) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0]; <span>}</span> <span><strong>public</strong></span> <span><strong>void</strong></span> setSession(Session session) <span>{</span> this.session = session; <span>}</span> <span><strong>protected</strong></span> <span><strong>void</strong></span> getSession() <span>{</span> <span><strong>if</strong></span> (session == <span><strong>null</strong></span>) session = HibernateUtil.getSessionFactory().getCurrentSession(); <span><strong>return</strong></span> session; <span>}</span> ... </t></t></t></t></code>
The controller now uses these stateless data access objects through direct instantiation:
<code><span>// EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED)</span> <span><strong>public</strong></span> <span><strong>void</strong></span> execute() <span>{</span> <span>// JTA: UserTransaction utx = jndiContext.lookup("UserTransaction");</span> <span>// JTA: utx.begin();</span> <span>// Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction();</span> ItemDAO itemDAO = <span><strong>new</strong></span> ItemDAOHibernate(); UserDAO userDAO = <span><strong>new</strong></span> UserDAOHibernate(); Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, <span><strong>true</strong></span>); newBid = item.placeBid(userDAO.findById(userId, <span><strong>false</strong></span>), bidAmount, currentMaxBid, currentMinBid); <span>// JTA: utx.commit(); // Don't forget exception handling</span> <span>// Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling</span> <span>}</span> </code>
The only disadvantage of this very simple strategy is that the implementation classes (i.e. ItemDAOHibernate and UserDAOHibernate) of the persistence layer are again exposed to the client, the controller. You can still supply a custom Session if needed (integration test, etc).
Each of these methods (factories, manual injection, lookup) for setting the current Session and creating a DAO instance has advantages and drawbacks, use whatever you feel most comfortable with.
Naturally, the cleanest way is managed components and EJB 3.0 session beans:
Writing DAOs as managed EJB 3.0 components
Turn your DAO superclass into a base class for stateless session beans (all your concrete DAOs are then stateless EJBs, they already have a business interface). This is basically a single annotation which you could even move into an XML deployment descriptor if you like. You can then use dependency injection and get the "current" persistence context provided by the container:
<code>@Stateless <span><strong>public</strong></span> <span><strong>abstract</strong></span> <span><strong>class</strong></span> GenericHibernateDAO<t id><strong>extends</strong> Serializable> <span><strong>implements</strong></span> GenericDAO<t id> <span>{</span> <span><strong>private</strong></span> Class<t> persistentClass; @PersistenceContext <span><strong>private</strong></span> EntityManager em; <span><strong>public</strong></span> GenericHibernateDAO() <span>{</span> setSession( (Session)em.getDelegate() ); <span>}</span> ... </t></t></t></code>
You can then cast the delegate of an EntityManager to a Hibernate Session.
This only works if you use Hibernate as a Java Persistence provider, because the delegate is the Session API. In JBoss AS you could even get a Session injected directly. If you use a different Java Persistence provider, rely on the EntityManager API instead of Session. Now wire your DAOs into the controller, which is also a managed component:
<code>@Stateless <span><strong>public</strong></span> <span><strong>class</strong></span> ManageAuctionController <span><strong>implements</strong></span> ManageAuction <span>{</span> @EJB ItemDAO itemDAO; @EJB UserDAO userDAO; @TransactionAttribute(TransactionAttributeType.REQUIRED) <span>// This is even the default</span> <span><strong>public</strong></span> <span><strong>void</strong></span> execute() <span>{</span> Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, <span><strong>true</strong></span>); newBid = item.placeBid(userDAO.findById(userId, <span><strong>false</strong></span>), bidAmount, currentMaxBid, currentMinBid); <span>}</span> <span>}</span> </code>
P.S. Credit has to be given to Eric Burke, who first posted the basics for this pattern on his blog. Unfortunately, not even the Google cache is available anymore.
A Better typed Generic DAO? You decide!
We are missing something on
<code><span>// Our common Model interface that an abstract Domain model will implement and all domain // models will extend.</span> <span><strong>public</strong></span> <span><strong>interface</strong></span> IModel<id><strong>extends</strong> Serializable> <span>{</span> <span><strong>public</strong></span> <span><strong>abstract</strong></span> ID getId(); <span><strong>public</strong></span> <span><strong>abstract</strong></span> <span><strong>void</strong></span> setId(<span><strong>final</strong></span> ID pId); <span>}</span> <span>// Our generic DAO, NOTE: MODEL's ID type is the same as ID now, which makes sense.</span> <span>// Also model type is more restrictive, dis-allowing all kinds of funky stuff to go in.</span> <span><strong>public</strong></span> <span><strong>abstract</strong></span> <span><strong>class</strong></span> GenericHibernateDAO<model><strong>extends</strong> IModel<id>, ID <span><strong>extends</strong></span> Serializable> <span><strong>implements</strong></span> GenericDAO<t id> <span>{</span> <span><strong>private</strong></span> Class<model> persistentClass; <span><strong>private</strong></span> Session session; <span><strong>public</strong></span> GenericHibernateDAO() <span>{</span> <span>// FIXME : I don't like magic number in the code, is there any way to fix 0 to something dynamic?</span> this.persistentClass = (Class<model>) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0]; <span>}</span> <span><strong>public</strong></span> <span><strong>final</strong></span> <span><strong>void</strong></span> setSession(<span><strong>final</strong></span> Session pSession) <span>{</span> this.session = session; <span>}</span> <span><strong>protected</strong></span> <span><strong>void</strong></span> getSession() <span>{</span> <span><strong>if</strong></span> (session == <span><strong>null</strong></span>) session = HibernateUtil.getSessionFactory().getCurrentSession(); <span><strong>return</strong></span> session; <span>}</span> ... </model></model></t></id></model></id></code>
In addition, we could add things like:
<code><span><strong>public</strong></span> <span><strong>final</strong></span> String getRootAlias()<span>{</span> this.getPersistentClass().getSimpleName() + String.valueOf(<span>'_'</span>); <span>}</span> </code>
Alhough this is not necessary or part of the enhanced version, but when criteria API is in use, this comes in handy.

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics











SQL IF statements are used to conditionally execute SQL statements, with the syntax as: IF (condition) THEN {statement} ELSE {statement} END IF;. The condition can be any valid SQL expression, and if the condition is true, execute the THEN clause; if the condition is false, execute the ELSE clause. IF statements can be nested, allowing for more complex conditional checks.

Methods to solve the cross-domain problem of Vue Axios include: Configuring the CORS header on the server side using the Axios proxy using JSONP using WebSocket using the CORS plug-in

How to configure Zend in Apache? The steps to configure Zend Framework in an Apache Web Server are as follows: Install Zend Framework and extract it into the Web Server directory. Create a .htaccess file. Create the Zend application directory and add the index.php file. Configure the Zend application (application.ini). Restart the Apache Web server.

The advantage of multithreading is that it can improve performance and resource utilization, especially for processing large amounts of data or performing time-consuming operations. It allows multiple tasks to be performed simultaneously, improving efficiency. However, too many threads can lead to performance degradation, so you need to carefully select the number of threads based on the number of CPU cores and task characteristics. In addition, multi-threaded programming involves challenges such as deadlock and race conditions, which need to be solved using synchronization mechanisms, and requires solid knowledge of concurrent programming, weighing the pros and cons and using them with caution.

The main reasons why you cannot log in to MySQL as root are permission problems, configuration file errors, password inconsistent, socket file problems, or firewall interception. The solution includes: check whether the bind-address parameter in the configuration file is configured correctly. Check whether the root user permissions have been modified or deleted and reset. Verify that the password is accurate, including case and special characters. Check socket file permission settings and paths. Check that the firewall blocks connections to the MySQL server.

This article describes how to effectively monitor the SSL performance of Nginx servers on Debian systems. We will use NginxExporter to export Nginx status data to Prometheus and then visually display it through Grafana. Step 1: Configuring Nginx First, we need to enable the stub_status module in the Nginx configuration file to obtain the status information of Nginx. Add the following snippet in your Nginx configuration file (usually located in /etc/nginx/nginx.conf or its include file): location/nginx_status{stub_status

The key to PHPMyAdmin security defense strategy is: 1. Use the latest version of PHPMyAdmin and regularly update PHP and MySQL; 2. Strictly control access rights, use .htaccess or web server access control; 3. Enable strong password and two-factor authentication; 4. Back up the database regularly; 5. Carefully check the configuration files to avoid exposing sensitive information; 6. Use Web Application Firewall (WAF); 7. Carry out security audits. These measures can effectively reduce the security risks caused by PHPMyAdmin due to improper configuration, over-old version or environmental security risks, and ensure the security of the database.

VprocesserazrabotkiveB-enclosed, Мнепришлостольностьсясзадачейтерациигооглапидляпапакробоглесхетсigootrive. LEAVALLYSUMBALLANCEFRIABLANCEFAUMDOPTOMATIFICATION, ČtookazaLovnetakProsto, Kakaožidal.Posenesko
