Researching Patterns and Practices
Since Friday, I’ve been researching a bit here and there about Object-Relational Mapping (ORM) and Model-View-Controller (MVC) at work and at home. These are technologies that help with manageable programming.
ORM is used to help store objects within a relational database. A database stores data differently then an object. This technique is used to map data between objects and databases. A popular and open-source tool to assist in this mapping for programming in .Net is nHibernate. nHibernate is a port of Hibernate written in JAVA. I have figured out the basics of saving and retrieving objects to a relational database. Though I’m starting to have difficulty with polymorphism in inheritance. I’ll keep up the R&D until I get it rite. So far, the technologies involved are showing a lot of promise. On top of that, I have found many websites offering supporting documentation and techniques that apply to both platforms on JAVA and .Net.
Model-View-Controller (MVC) can work with or without ORM. ORM would only be used with the Model portion of MVC. MVC breaks your application (desktop or web applications) into three parts. Model represents your business elements, or data schemata. “View” represents the final web page, also known as your “presentation layer”. Last we have “Controller” wich is the business logic between your presentation and your data. Business logic can manipulate data, authorize that you do in fact have permission to access that data, and just about everything else. It can be thought of as the API undernieth the presentation itself. Some people claim that it is the glue between the data and the presentation.
I’ve worked with MVC often, but not to its full effect. The rules with MVC pretty much go something like this. If any one part of MVC changes (The model, view, or controller), then the other two parts should not break. That is the part where I am not successful. I usually develop 3 projects initially in my applications. The web or desktop application, a project for business logic, and another project for the data tier.
I believe most of my problems arrise from the stability of the model. As long as the model doesn’t change, the control and view should be able to change more easily without any impact. I’ve originally kept a virtual model in place and manually mapped it to an older model that was practically inherited from another project. This worked great in the first phase as there were very simple requirements and tight deadline.
In this second phase, requirements change every day and are still being gathered. After much research into ORM and MVC, I am wanting to just get a definition of the domain that I can rearchitect the model after. Currently, I am having to rearchitect the older model many times due to its current incompatabilities with the requirements. This still raises a problem though for future architecture. How can a database be architected properly to be able to grow not in data scalability, but in schemata scalability? I understand normalization as such, but the current model already has normalization and needs to be reworked often when changes to requirements occur.