Difference between revisions of "Application Dictionary"

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
m (At the View Layer)
(conclusion)
Line 31: Line 31:
 
*The Accessory portion is isolated from all the others so that it can function without any bug introduced into it from the other layers. The developers are left free to modify the Application Dictionary as the business demands.
 
*The Accessory portion is isolated from all the others so that it can function without any bug introduced into it from the other layers. The developers are left free to modify the Application Dictionary as the business demands.
 
*Logic that are not handled in the above layers are handled by Callouts and Model Classes under the control of the [[ModelValidator]].
 
*Logic that are not handled in the above layers are handled by Callouts and Model Classes under the control of the [[ModelValidator]].
 +
*Core business logic processes such as Aging Analysis, Convert Requisition to PO or Complete Orders are handled by Java classes that are called by the AD Report & Process engine. Input parameter selection are facilitated for easy configuration by the developer without much supportive coding in the fully Object Oriented Java environment.
 +
 +
=Conclusion=
 +
*ERP is complex and an ERP Software Application can be even more complex. The role of the AD is very vital and ingenious in dealing away with as much complexity of the software components as possible to leave the users a comfortable learning curve into the application.
  
 
[[Category:Developer documentation]]
 
[[Category:Developer documentation]]
 
[[Category:Training Course]]
 
[[Category:Training Course]]

Revision as of 18:26, 25 September 2008

Please Improve

  • This is just trying to make sense of the power of the AD. By no means authoritative yet. - Red1 21:04, 25 September 2008 (EDT)

Introduction

  • Basically the architecture or model of ADempiere is based on Compiere's Application Dictionary or AD Engine. It resolves the Model-View-Logic model of modern software design.
  • AD's Model Layer takes care of all the entities such as the core database table & field structure, its datatype, reference and validation rules.
  • AD's View Layer takes care of its presentation in both the Java and HTML clients without the developer needing to code a single line of extra user interface code.
  • AD's Logic Layer is where all the business logic and auxilary activity happens.
  • The software is built from the ground up with inherent capabilities namely the MULTIs features such as multi-language, multi-org, multi-currencies, and Log4Java debugging set, and powerful Java Objects such as Environment & Context, Persistence, Web and Application Service.
  • Its CRM and Webstore components are custom-built and thus do not fully rely on the AD.
  • The AD Engine is very powerful that it enforces discipline in the the software application to separates its tasks into distinct layers and allow the developer to dive straight into business functionality without messing around with the software code.

At the Model Layer

  • All Table and Field structure are defined in the AD Table & Column window.
  • Each field's properties such as datatype and reference are defined in the same window.
  • A field can possess validation rule and which is defined in the AD Validation window
  • Any changes to the model such as introducing a new table to the database is done via the AD Table & Column window.
  • The AD Engine resolves the preparation of the table and field structure for the View level or outputs such as displaying via the user interfaces or reporting formats.

At the View Layer

  • As the Model is taken care of, the View Layer shall present the Model to the UI be it the Java Swing or HTML Clients.
  • All CRUD (create, read, update, delete) functions are automatically taken care and shall appear in the client interfaces without any further changes or effort during definition of new model changes.
  • The UI is aware of new records, mandatory fields and saving errors.
  • It allows powerful search functions and field preference setting according to the User ID.
  • The View Layer is handled by AD Menu, AD Window and AD Process & Report
  • They communicate with the earlier Model Layer efficiently.

At the Logic Layer

  • Alot of visible power of the ERP Application happens here beginning with auxilary and accesorry functions such as User Login, Role Access and Workflow reactions.
  • In a way, the Logic Layer is further separated from this Accesory portion as its own Business Logic area which the functional developer is most interested in.
  • The Accessory portion is isolated from all the others so that it can function without any bug introduced into it from the other layers. The developers are left free to modify the Application Dictionary as the business demands.
  • Logic that are not handled in the above layers are handled by Callouts and Model Classes under the control of the ModelValidator.
  • Core business logic processes such as Aging Analysis, Convert Requisition to PO or Complete Orders are handled by Java classes that are called by the AD Report & Process engine. Input parameter selection are facilitated for easy configuration by the developer without much supportive coding in the fully Object Oriented Java environment.

Conclusion

  • ERP is complex and an ERP Software Application can be even more complex. The role of the AD is very vital and ingenious in dealing away with as much complexity of the software components as possible to leave the users a comfortable learning curve into the application.