I have finished “fixes” on some project that was developed by typical J2EE team and needed to made work before it enters official beta. It has been extremely difficult to navigate and resolve and I would like to provide a brief checklist of symptoms you might want to review to see if your project is heading for trouble:
Symptom #1. The sizable project is built very much on Flex framework without layer of UI controls for common business and UI functionality. Typical of shops that think of MXML as another xHTML.
Problem: Impossible to enforce consistent behavior across multiple screens, cumbersome user input, complicated formatting and validation, tons of “cut and paste” spaghetti code and millions of bugs.
Solution: Extend MXML controls into business controls that would make reusable UI elements with ROBUST and SIMPLE interface. Make sure that your controls are perfect to the end-users of your application. Strive for data-driven application programming.
Symptom #2. Conventional J2EE middle tier that does nothing but repackages data for DB/XML communications.
Problem: It usually does something in reality. It might prevent you from using transactional capabilities in database. It can hide errors from the back-end. It might contain bugs. Cause performance degradation and scalability issues.
Solution: Either go directly to the datasource or base your data entry systems on the model with client-centric updates. Provide direct feedback on the errors, transactional control, eliminate duplication and integration problems.
Symptom #3: Cairngorm framework for large application. I am going to get a lot of flame mail on that one.
Problem: Nevertheless, I was saying it 15 years ago, and I say it again – do not use framework unless you build application identical to the one the framework was built for. Unfortunately, RIA area is much wider than old “shopping cart/content management” Web we know of – there is slim chance that any framework will be more of help then a burden unless you indeed are building shopping cart. Framework is not a silver bullet, but rather a way to postpone design stage.
Solution: Start with class libraries. Build and verify reusable components early. You are in object-oriented, event-driven, real-world facing environment that has to be intelligent and friendly to the end-user. Break your application into libraries and modules as early as you can – it will pay off faster then you think.
Symptom 4#: Excessive use of binding.
Problem: You try to see dependencies, and it just never ends. Cycles, breaks, using binding for initialization, wrong timing – you name it. Debugging becomes time consuming and very challenging. As a result – untested code that seems to work.
Solution: Understand the difference between binding, initialization and types of the events you really want to listen to. Handle events locally in the business domain UI components. Do not force system to do more then it needs. In the event driven environment you really want to keep the noise down -especially for large applications.
Symptom 5#: No error handling, no logging statement and assertions in the code.
Problem: I can be wrong here. It is possible that the code is perfect and nothing is going to break ever. Otherwise, you are doomed. Seriously, bringing support phone into your bedroom is not thing you want to do. Postponing the problems after release date will get you in trouble.
Solution: I will blog a bit more next week and make sure we will release some of the internal tools in the circulation this month. There is no excuse not to use logging API and assertion in Flex.