How to simplify MDD for speeding Java Enterprise Development?

Discussions

News: How to simplify MDD for speeding Java Enterprise Development?

  1. A notable problem of Java Enterprise Development is its inherent complexity. Either if you use Java EE standard or Spring, your development team will never be as productive as a VisualBasic, PHP, Ruby&Rails, 4GL or even COBOL development team. Complexity of Java Enterprise requires very skilled developers, moreover these developers need to write a lot of code. The ideal solution for this problem could be the Model-Driven Development approach. Basically MDD states that just the model part of an application has to be developed, and the rest of the application will be generated from this model. In this way, the developers write less and simpler code, nevertheless a powerful Java Enterprise Application is created. However, for today, the MDD usage is still very complex. It's needed to make a big investment of time, expertise, and tooling; usually building your own DSL's and combining them into a software factory, and it costs a lot of effort. Therefore, only big companies can afford MDD, and it can only be paid back when using it multiple times for different projects. And, of course, MDD is a hard alternative for mid-size and small companies. Fortunately you can enjoy the goodness of MDD without its pains. Just removing MDA, DSLs, UML and code generation from MDD and you'll obtain a simple but effective way to do Model Driven Development. The Better Software with Less Code white paper examines how to do Model Driven Development in a lightweight way, so it could be affordable for small and mid-size companies, and cheaper for the big ones.
  2. your development team will never be as productive as a VisualBasic, PHP, Ruby&Rails, 4GL or even COBOL development team
    Why do I need MDD (now my system has huge development dependencies) when I can train my development team on VisualBasic, PHP, Ruby&Rails, or a 4GL to close the gap. Use Enterprise Java for services that clients can consume. With Clouds and RIA and all sorts of other game-changers, by the time I get a MDD solution in place technology will have moved in a new direction.
  3. your development team will never be as productive as a VisualBasic, PHP, Ruby&Rails, 4GL or even COBOL development team
    Undisputed at TSS.
  4. It's tragic in this day and age to see an example like this: @Entity public class Teacher { @Id @Column(length=5) @Required private String id; @Column(length=40) @Required private String name; where id and name are realy types with both database storage and GUI display requirements in and of themselves. Then an anotation is used inside the teacher class to state some of these. Hopefully the programmer gets them right in all other places they are also used. At least the id will be in objects telling us what the teacher teaches. I don't know other parts of OpenXava. It is probably a very good product. My main aim here is to make clear that even someone who try to do something advanced today realy haven't gotten much further than we where in the 1980's when it comes to the things shown above. We live in a tragic world that moves so slowly forwards.
  5. OpenXava[ Go to top ]

    OK, so this is about OpenXava: http://www.openxava.org Why is that information not in the title?
  6. Re: OpenXava[ Go to top ]

    OK, so this is about OpenXava: http://www.openxava.org

    Why is that information not in the title?
    Really the White Paper is about LightWeight Model-Driven Framework vs classical Model-Driven Development. OpenXava is only an example of this type of frameworks, there are more, such as Trails, NakedObject, RomaFramework or JMatter.
  7. Nils, Please could you explain a little more why having the validation info in the class Teacher is bad.
  8. where id and name are realy types with both database storage and GUI display requirements in and of themselves. Then an anotation is used inside the teacher class to state some of these.
    Yes. In fact, this is the key feature of OpenXava. It is Business Component oriented. This means that all stuff about a business concept is in the same place. Instead of organize the code of our application into user interface, business logic, database access, etc. we organize the code into Invoice, Delivery, Customer, etc. It's only a different way to sort the things. If you change more frequently the data structure and business model than the technology for database or UI, then the business component approach is more practical. With OpenXava when you need to add a new property with some logic to an Invoice, you only have to change the Invoice.java resource. You have not to touch, seven java files and 2 XMLs in order to accomplish such simple and habitual change. That is, mixing database info, UI info, data structure and business logic in the same file, is a sin for you, but not from a Business Component perspective. About the Annotated POJOs cluttering problem. When you see a property (for example) you have at hand all the aspects of the property at once, from UI to Database, this is the best in most case. Anyways, you can create a simple plugin for your IDE that can show/hide the annotations by package.
  9. Sorry Javier. Taking a look at the OpenXava, it looks like it is a powerful framework, it is worth a try. Now, the MDD part is the one I think that is missing the point. You see, modeling means to work with components that are inside a domain, and that are ruled by a set of constrains and relations, all those dictated by the domain itself. If you are working to solve a surgery problem, you will need to talk about surgeons, nurses, surgery tools and such. You will use those components to solve the issue. Of course, Java does not have those concepts in the the language. So, you cannot use Java to model that. Instead, you use a DSL, a specialized language that contains those concepts and is more natural to work with. Later on, you can convert those DSL instructions into java, no problem. From what I see, please correct me if I'm wrong, the concept of model that is used in the white paper is that of MVC (that is incorrectly used, anyways). The Model of the MVC is usually taken as the data, or database. If so, that has not much to do with the Model concept of MDD. They are different (in practice). Don't get me wrong. When we say model, it is model, as abstraction of a reality, in the scope of a domain. Model is not just data. So it should be in MVC.
    William Martinez Pomares.
    Architect's Thoughts
  10. Taking a look at the OpenXava, it looks like it is a powerful framework, it is worth a try.

    Now, the MDD part is the one I think that is missing the point. You see, modeling means to work with components that are inside a domain, and that are ruled by a set of constrains and relations, all those dictated by the domain itself. If you are working to solve a surgery problem, you will need to talk about surgeons, nurses, surgery tools and such. You will use those components to solve the issue.
    Exactly!
    Of course, Java does not have those concepts in the the language. So, you cannot use Java to model that.
    I don't agree The classes are just for that, for model concepts of the reality. The idea of the white paper is that you can use simple Java classes with annotations for modeling instead of a DSL.
    Instead, you use a DSL, a specialized language that contains those concepts and is more natural to work with. Later on, you can convert those DSL instructions into java, no problem.
    The version 1 and 2 of OX worked in this way. The OX3, that work directly with Java with annotations, is more practical because: 1. It doesn't use code generation. Now, you touch the code, and you see the change in your browser instantly. 2. You can use standard Java tools for write your code. 3. You can convert any already existing Java application that uses POJOs and JPA to OpenXava easily. 4. If you already know JPA, Hibernate Validator, etc. you already know how to develop an OpenXava application
    From what I see, please correct me if I'm wrong, the concept of model that is used in the white paper is that of MVC (that is incorrectly used, anyways).The Model of the MVC is usually taken as the data, or database.
    Though in the OX documentation we have parts for Model, View and Controller, OpenXava is not a MVC framework. In OX the controller has only the behaviour of the the application, but the pure business logic is in the model. The model in OX is not just a wrapper around data. I always encourage to OX developer to move the logic from controller to model when possible. At the end the model classes have not only data structure and business logic, but validation, UI info, database info, etc. Maybe, talking about Business Compoment is better.
  11. A notable problem of Java Enterprise Development is its inherent complexity. Either if you use Java EE standard or Spring, your development team will never be as productive as a VisualBasic, PHP, Ruby&Rails, 4GL or even COBOL development team. Complexity of Java Enterprise requires very skilled developers, moreover these developers need to write a lot of code.

    Is there anyone who thinks that this "inherent" complexity is simply caused by inadequate "best practices" ? Just a simple list: 1. DAO-per-class with transaction boundaries in each method. 2. DAO with ORM 2.1 DAO with ORM with transaction boundaries in each method. 3. EJB for business logic when non necessary (when is it necessary ?) When people will start designing their applications without googling around and implement their design at least once in a lifetime, maybe life would be easier. Guido
  12. I have similar concerns: http://fromapitosolution.blogspot.com/2008/11/simple-and-practical-model-driven.html