139.149.1.230 (talk) |
|||
Line 8: | Line 8: | ||
The term "POJO" is mainly used to denote a Java object which does not follow any of the major Java object models, conventions, or frameworks such as EJB. The term continues the pattern of older terms for technologies that do not use fancy new features, such as POTS ([[Plain Old Telephone Service]]) in [[telephony]], and PODS ([[Plain Old Data Structures]]) that are defined in [[C++]] but use only [[C (programming language)|C]] language features, and POD (Plain Old Documentation) in [[Perl]]. The equivalent to POJO on the [[.NET framework]] is [[Plain Old CLR Object]]. |
The term "POJO" is mainly used to denote a Java object which does not follow any of the major Java object models, conventions, or frameworks such as EJB. The term continues the pattern of older terms for technologies that do not use fancy new features, such as POTS ([[Plain Old Telephone Service]]) in [[telephony]], and PODS ([[Plain Old Data Structures]]) that are defined in [[C++]] but use only [[C (programming language)|C]] language features, and POD (Plain Old Documentation) in [[Perl]]. The equivalent to POJO on the [[.NET framework]] is [[Plain Old CLR Object]]. |
||
==Contextual variations== |
|||
package com.wipro.db; |
|||
The POJO phenomenom has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks. A [[JavaBean]] is a POJO that is [[Serialization#Java|serializable]], has a no-argument [[Constructor (computer science)|constructor]], and allows access to properties using [[Mutator method|getter and setter methods]]. An [[Enterprise JavaBean]] is not a single class but an entire component model (again, [[Enterprise JavaBean|EJB 3]] reduces the complexity of Enterprise JavaBeans). As designs using POJOs have become more commonly-used, systems have arisen that give POJOs some of the functionality used in frameworks and more choice about which areas of functionality are actually needed. [[Hibernate (Java)|Hibernate]] and [[Spring framework|Spring]] are examples. |
|||
/* |
|||
* To change this template, choose Tools | Templates |
|||
* and open the template in the editor. |
|||
*/ |
|||
Ideally speaking, a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification. I.e., a POJO '''should not''' have to |
|||
//package employeemanagement; |
|||
<ol> |
|||
<li>Extend prespecified classes, as in |
|||
import java.io.BufferedReader; |
|||
<source lang="java">public class Foo extends javax.servlet.http.HttpServlet { ...</source> |
|||
import java.io.InputStreamReader; |
|||
</li> |
|||
import java.sql.Connection; |
|||
<li>Implement prespecified interfaces, as in |
|||
import java.sql.DriverManager; |
|||
<source lang="java">public class Bar implements javax.ejb.EntityBean { ...</source> |
|||
import java.sql.PreparedStatement; |
|||
</li> |
|||
import java.sql.SQLException; |
|||
<li>Contain prespecified annotations, as in |
|||
<source lang="java">@javax.ejb.Entity public class Baz{ ...</source></li> |
|||
/** |
|||
</ol> |
|||
* |
|||
However , due to technical difficulties and other reasons, many software products or frameworks described as POJO-compliant actually still require the use of prespecified annotations for features such as persistence to work properly. |
|||
* @author admin |
|||
*/ |
|||
public class Employee { |
|||
public static void main(String[] args) { |
|||
mainMenu(); |
|||
} |
|||
/*Creting main method for main menu*/ |
|||
public static void mainMenu(){ |
|||
try { |
|||
System.out.println("----------M E N U ---------------------"); |
|||
System.out.println("1---------ADD EMPLOYEE"); |
|||
System.out.println("2---------DELETE EMPLOYEE"); |
|||
System.out.println("3---------EXIT EMPLOYEE"); |
|||
System.out.println("---------------------------------------"); |
|||
BufferedReader br=new BufferedReader(new InputStreamReader(System.in)); |
|||
System.out.println("Enter the choice --- "); |
|||
String s; |
|||
s=br.readLine(); |
|||
switch(Integer.parseInt(s)) { |
|||
case 1: { |
|||
/*add employee detail*/ |
|||
//add_emp_detail a =new add_emp_detail(); |
|||
//a.adddetail(); |
|||
System.out.println("Supply Input"); |
|||
int noOfRecords = adddetail(); |
|||
System.out.println("noOfRecords==>"+noOfRecords); |
|||
break; |
|||
} |
|||
case 2: { |
|||
System.out.println("Inside delete emplloyee --- "); |
|||
break; |
|||
} |
|||
case 3: { |
|||
System.exit(0); |
|||
} |
|||
default:System.out.println("Please Enter a valid choice!"); |
|||
break; |
|||
} |
|||
} catch(Exception e) { |
|||
e.printStackTrace(); |
|||
} |
|||
} |
|||
public static int adddetail() { |
|||
PreparedStatement pstmt; |
|||
int noOfRecord = 0; |
|||
try{ |
|||
Class.forName("oracle.jdbc.driver.OracleDriver"); |
|||
Connection con = DriverManager.getConnection("jdbc:oracle:thin:@sldn8002vdor.ldn.swissbank.com:1553:RKYCD3","RKYC_COT_01","dcot4"); |
|||
System.out.println("con==========="+con); |
|||
pstmt = con.prepareStatement ("insert into CONTACT(FIRSTNAME, LASTNAME, EMAIL, ID) "+ "values(?,?,?,?)"); |
|||
pstmt.setString(1,"ADDD"); |
|||
pstmt.setString(2,"Kumar"); |
|||
pstmt.setString(3,"raj@gmail.com"); |
|||
pstmt.setInt(4,101); |
|||
noOfRecord = pstmt.executeUpdate(); |
|||
} catch (ClassNotFoundException e) |
|||
{ |
|||
e.printStackTrace(); |
|||
} catch (SQLException e) { |
|||
e.printStackTrace(); |
|||
} |
|||
return noOfRecord; |
|||
} |
|||
} |
|||
==POJO generation projects== |
==POJO generation projects== |
Revision as of 14:00, 13 January 2010
In computing software, POJO is an acronym for Plain Old Java Object. The name is used to emphasize that a given object is an ordinary Java Object, not a special object, and in particular not an Enterprise JavaBean. The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000:
"We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely."[1]
The term "POJO" is mainly used to denote a Java object which does not follow any of the major Java object models, conventions, or frameworks such as EJB. The term continues the pattern of older terms for technologies that do not use fancy new features, such as POTS (Plain Old Telephone Service) in telephony, and PODS (Plain Old Data Structures) that are defined in C++ but use only C language features, and POD (Plain Old Documentation) in Perl. The equivalent to POJO on the .NET framework is Plain Old CLR Object.
Contextual variations
The POJO phenomenom has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks. A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods. An Enterprise JavaBean is not a single class but an entire component model (again, EJB 3 reduces the complexity of Enterprise JavaBeans). As designs using POJOs have become more commonly-used, systems have arisen that give POJOs some of the functionality used in frameworks and more choice about which areas of functionality are actually needed. Hibernate and Spring are examples.
Ideally speaking, a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification. I.e., a POJO should not have to
- Extend prespecified classes, as in
public class Foo extends javax.servlet.http.HttpServlet { ...
- Implement prespecified interfaces, as in
public class Bar implements javax.ejb.EntityBean { ...
- Contain prespecified annotations, as in
@javax.ejb.Entity public class Baz{ ...
However , due to technical difficulties and other reasons, many software products or frameworks described as POJO-compliant actually still require the use of prespecified annotations for features such as persistence to work properly.
POJO generation projects
- Roma Meta Framework
- DDD centric framework. The innovative holistic approach lets the designer/developer to view anything as a POJO: GUI, I18N, Persistence, etc.
- OpenXava
- Framework to develop J2EE business applications rapidly and easily. It's based in business components defined with XML. Feature rich and flexible since it's used for years to create business applications. Generates POJO Hibernate EJB2 and EJB3 JPA ...
- PlainXML
- Generating POJO by DTD; XML-POJO mapping via Java5 annotations or DTD; XML manipulations using POJO without SAX/DOM; Preprocessing of XML documents using expression language; Binary XML; RMI friendly XML; Exporting to JSON; XML marshall/unmarshall ...
- PAT
- AOP (JBossAOP) persistence library (aspect library). Provides persistence layer with underlying Prevayler (1.02). Allows users to write their code without worrying about persistence code (POJO). Uses annotations...
- Java O/RM
- This is a Java Object Relational mapping tool that is very simple to use. It works with all major databases and requires only minimal coding effort. JOR strictly follows the POJO / POJI (Plain Old Java Objects / Plain Old Java Interfaces) model...
- AutoPersistJ
- This project aims to assist developers in developing java EE persistence layer for existing database tables. It gets metadata of selected database tables and generates classes for them. it uses and extends the ideas of DbGen project to EJB 3.0 POJO...
- PojoGen
- It is a small tool to generate Java Code (a POJO) for an APPFUSE-based project from a DDL file, which is created from an ER diagram by Microsoft VISIO. It makes an APPFUSE-based project more easy to use.
- Pojodbc
- An easy to use Java Object Relation mapping library without configurations file or annotations. Build on top of JDBC, you still use your optimized native SQL and get POJOs.
- Apache Felix iPOJO
- A new type of dynamic service-oriented component runtime that runs pure POJO applications on the top of OSGi plateforms. Non-functional (extra-functional) services can be added and removed at runtime.
- JBoss Microcontainer
- The JBoss Microcontainer is a refactoring of JBoss's JMX Microkernel to support direct POJO deployment and standalone use outside the JBoss application server.
- Naked Objects
- An open source framework that auto-creates an object-oriented user interface from POJOs using the naked objects pattern.
- Metawidget
- A 'smart User Interface widget' that populates itself, at runtime, with UI components to match the properties of POJOs.
- fbDaoGenerator
- Fbdaogenerator connects to a Firebird Database, reads the metadata of the Database by querying the system-tables, and generates POJOs and Data Access Objects.
References
- ^ MF Bliki: POJO from MartinFowler.com