Published the third part of this serie about the use of MVC with Delphi.

Published the third part of this serie about the use of MVC with Delphi.

We present now our ORM classes generator. This piece of code is going to be very important in our project, but it can be used as a separate piece of code in a lot of circumstances.

Included the first battery of Unit Tests. Remembering us what is our objective of implementing MVC in our project:

"Construct code without errors that demonstrates itself that all the functionalities have been proven and then protects these functionalities over the changes made over time"

https://sencille.wordpress.com/2016/03/21/3-sencille-mvc-orm-generator-tests/
https://sencille.wordpress.com/2016/03/21/3-sencille-mvc-orm-generator-tests/

Comments

  1. It sounds more like a DRM than an ORM to me. A DataSet / Relational / Mapper. There is no real object/class storing the information, here. Or did I miss something?

    ReplyDelete
  2. A. Bouchez
    The data taken to generate an object, change the objective of this object?

    It's a ORM class without doubt!

    Each object generated with this tool can hold ONE LINE, representing a Row of the Database.

    I recommend you, download the code and take a look to the Unit Tests.

    As you can see, the ORM generated is based in TFields and It has, internally, a Dataset.

    But... it's not a Dataset. It's an ORM class.

    Thank's for comment.

    ReplyDelete
  3. Difficult to follow the tests. Some generated units like ORMCategory, ORMCustomer, ORMEmployee, ORMOrder, ORMProduct, ORMShipper, ORMSupplier are missing from the repository.
    As you state, the TCustomOrm base class host its own TClientDataSet, and all the "magic" is still at TDataSet level. You are not creating any SQL process, nor leveraging the relational model at all. I'm sorry, this is not an ORM. Just go back to the definition. You cannot create the tables. And I was not even able to find out how to make a parametrized query. And in terms of performance... a nightmare...
    So it sounds to me like an Object ClientDataSet Mapping. Fine if you need it. But I don't buy the "ORM" feature here.

    ReplyDelete
  4. A. Bouchez
    The objetive of an ORM class never was the creation of any table!!!! Nor creation of parametrized queries!!!

    ORM is a technique to solve the Object-relational "impedance mismatch".

    About the classes missing, I'm going to check this, but if you want you can create them again, with the ORMGenerator.

    If you read the blog, you can see that, actually over this classes are only smoke test, and only one complete test. Is this complete prove what you can check to understand the objective.

    This is the third entry of this blog. The next post is going to be about the Model Layer. With a lot of new Unit Tests. In the fifth entry have planned the presentation of the Controller layer. And finally, may be in the sixth entry, we are going to present the view layer.

    One time the complete framework has been assembled, we are going to use it to change a lot of things of applications, without lost funcionalities. Transformation to mobile, or change the view layer for VCL, may be. I'm preparing too a version for Webservices and a version for a REST server. I repeat: With the same functionalities, and without changes in Model. Of course a good change is two or three differente database to all the projects.

    Performance? Can you speak about performance without make any metric? If you have not compile the code, you can't make metrics over it.

    Are basic principles of engineering!!!

    If you are interested in this theme, I recomend you subscribe to my blog. If you are interested in demonstrate that this is not ORM, I recomend you... ;)

    ReplyDelete
  5. As I wrote, such encapsulation of TClientDataSet does not solve impedance mismatch, since it does not involve any relational model at all. If you want to make a query, you have to provide the SQL statement to CreateQuery! Having to write the SQL is far from the definition of an ORM IMHO.
    I don't want to argue, your code has the benefit of being public. If you want the framework to be an ORM, you have to embrace both its theory and practice.
    Trust me, I know a little about those things. ;)
    If you just want to check what I mean with ORM performance, and why TClientDataSet is a bottleneck, see e.g.  http://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html#TITL_59

    ReplyDelete
  6. A. Bouchez
    You have not read the blog!
    You have not got a local copy of the repository!
    You have not understand what Unit Tests implies!

    And you ask me what? "Trust in me?" you said.

    Your only argument is: "I've seen a TClientDataSet in your code, because of this, this is not ORM".

    If you need help to get a local clone of the repository, I can help you.

    If you need help about what are UnitTests and how to run it, I can't recommend you a lot of places where get help.

    But if you don't read the blog, I can't do anything. I'm sorry.

    ReplyDelete
  7. I read all related blog posts and most of the framework source code (no need to clone it, you can read it online). Also note that my projects have extended unit tests. Extended here is billions of tests cases, not just a few dozen.
    I feel sorry you can't understand what I wrote here, obviously. I'm fine with TDataSet use, but ORM is beyond it. In short, it should abstract and hide
    the SQL used behind the scene, at last!
    Your work is nice and interesting, but IMHO it does not fit to the definition of an ORM, whatever you claim. Aurelius, EntityDac, DORM, mORMot are ORMs, just like Hibernate, EF or Doctrine outside Delphi.

    ReplyDelete
  8. A. Bouchez
    I'm sorry. Have a good day.

    ReplyDelete
  9. Stefan Glienke
    By example:
    "In my projects, I associate in a View, an ORM Object with each TreeViewItem. When the user Drags and Drops a TTreeViewItem between forms he is, literally, dragging and Object with all its properties…not a reference! But this is part of the View. Now we are speaking about ORM."

    But, this is explained in the text of the blog. Subscribe and see what we do with ORM classes in next posts.

    ReplyDelete
  10. I have the feeling that you are confusing some things here. MVC is about separating business logic from the UI. If you are using an ORM in an MVC application then the ORM is part of the Model. However if you call your project something MVC it should not have to deal with an ORM at all. If you combine both things it will just cause mixing the different layers.

    ReplyDelete
  11. Stefan Glienke
    I use the ORM objects as communication items between the layers.
    That empower the layer independency.

    ReplyDelete

Post a Comment