cancel
Showing results for 
Search instead for 
Did you mean: 

Validation required of model architecture

Former Member
0 Kudos

Hi All,

My group is currently designing a large Web Dynpro application, and part of my aim is to ensure we build this in a resuable and object-oriented approach. Obviously Web Dynpro ensures much of the solution is this way, however, I struck a bit of a snag when it comes to building a JAVA object model. Note - I've added some detail for anyone else who may be investigating this.

First some design considerations:

1. The version will be EP6 SP4.

2. Some data will be in R/3, while some will need to be on the EP Database. For some objects, data will be merged from both databases. I specifically don't want to model the data in two objects as this does not make sense, but want to model one object and specifically abstract the data retrieval to another layer yet again.

3. Open SQL will be used for EP Database access.

4. I feel till there is a possibility of stateful Web Services, that using Web Services just detracts away from OO design in terms of elegance and performance.

The design we came up with was as follows:

First we create a configuration model and a model class (which I feel should be called a model interface at this point until it can actually be an object). This model class represents the "interface" to the Model Class (Let's call this <b>InterfaceA</b>). Then I create a new Java class (say <b>ClassA</b>) within the Web Dynpro project (for those who didn't realize this, you can do this by going New->Other->Java->Class). I modify <b>ClassA</b> to implements <b>InterfaceA</b> and generate all the methods by clicking on the tag on the left of the class name.

Then within the controller, I map to <b>InterfaceA</b> within the context, and during the wdDoInit of the controller, I create an object of type <b>InterfaceA</b>, and instantiate it with the <b>ClassA</b>() constructor. I then bind this object to the Context. From this point onwards, we should then be able to keep this object in memory, and pass the object around to different views and controllers.

Questions in regards to this design:

1. Is this how it's meant to work?

2. Should we be using an EJB that implements InterfaceA (if that is possible)? If so, I believe I would lose the Adaptive RFC model for accessing R/3?

3.Once I bind the object to the Controller context, will that object be persistent while that application is running.

If you get through all that, thanks for reading and I appreciate any feedback.

Regards,

Matt

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Based on no feedback, I'm going to go ahead with this design and close out this question. It appears to be working fine for us.

I look forward to being able to define a Model class that can contain methods and hence SQLJ commands.

Note - I didn't add above that you need to create the model class as an interface and then you can define methods and properties which all components can use once they connect to the controller's context.

Cheers,

Matt