When building an application from scratch, should I start with the object-oriented (OO) model or the entity-relationship (ER) model?
Add a comment
|
2 Answers
You might want to try to observe the principle of delaying architectural decisions as long as possible. The thought goes, that you will know more in the future about your problem domain than you do right now - so, any decisions you make today are suspect.
Another good principle to pair this with might be to try to attempt the riskiest parts of your requirements first - the thought being that if you do the easy parts, then find that the risky parts move you in a different direction, you don't have to re-do the easy parts. Risky here meaning things you aren't sure how you should do them.
Given these two, and given that I often try to approach things from an OO perspective, you might try to start with an OO model of the riskiest parts of your application first, and implement a least possible amount of code that can work that satisfies the risky requirements. Then, begin expanding your OO model as needed to add functionality you are going to need. All the while, you can completely delay your decision on whether to use SQL or NoSQL or flatfiles or cloud storage or whatever ... and you may eventually find you don't want relational at all (obviating the need for an ER model).
The ER model dictates how the application's data will be persisted, and the OO model decides how that same data will be stored in memory, or while the application is running. So, Database schema design (ER model) and class stucture design (OO model) are related design considerations, and can usually even be thought about concurrently. In fact, if you are using an Object-relational mapping (ORM) tool, your ER model and your OO model may be one and the same. In other words, your classes (OO model) may be annotated in such a way that they, themselves, specify the ER model.
Before designing, though, make sure you have a very good idea of the actual requirements of the software, what it will be used for, how it will be used, and who will use it. Many developers start thinking about design decisions before they fully understand the needs to be addressed by the product, and end up with a design that is ill-suited for the true purpose of the application.
-
+1 for identifying the difference between the 2 types of modeling. I don't fully agree that you can think about the 2 models concurrently. Also, some OO fans consider that your OO and ER Models should not always be the same. However, an OO model may be used to as the basis of the database design but this transformation is a bit tricky.– NoChanceCommented Mar 13, 2012 at 17:06
-
@EmmadKareem You're right, it is not always appropriate to think of the two models concurrently. I was speaking in reference to the idea of using an ORM and annotating classes so the ER model design is integrated into the OO model, so to speak. Some people choose to develop applications in this way, which is essentially implementing both OO and ER concurrently.– CFL_JeffCommented Mar 13, 2012 at 17:11
-
Don’t mistake your domain model for a data model - Don’t confuse an object (which represents a single instance) with a database table (which contains a collection of things) Commented Aug 9, 2017 at 11:54