How do you organise your models?

(0) Share

Report

Posted on by Community Member

Originated from another post where we have started to discuss how to best leverage the models capabilities. The main question is, how do you structure your model?

Is one model = one solution or product?

How do you manage the dependencies between models?

How do you make sure the developers build the customisations always in the right model?

My personal understanding is that models are "containers" or deployment artifacts for solution. They should not be treated as AOT projects or replacement for XPOs.

Another question is, do you ensure that you test the models (or solutions) which you plan to distribute/reuse in other projects on its own, in an isolated environment?

One of my principles is that you should avoid developing more than one model within one project. Let's say you are and end user with your own development team: You can receive models from partners (one of them could be an industry solution, developed and tested separately; and another your individual customer solution) and install them into your test/build environment. Plus additionally you have an in-house developer team for reports, security and maybe forms. This is a separate model. In this scenario it is ensured that all the model are developed and tested on its own. There are no bi-directional dependencies (only in one way).

The original text Jonathan Halland wrote:

"There are some inter-dependencies between the models and these either just need to be considered or may need to be tested as you suggest.

E.G. Our Securities model is mostly a standalone model and can be frequently deployed on its own as we add and adjust roles.

It does contain some references to menu-items in the Customisations model. This just means that we need to be aware if a new menu-item has been added to the customisations model and the securities model has been adjusted to handle this menuitem we will need to deploy both models. However if only the securities model has changed then we can deploy it on its own. Also if we just change some code in the customisations model we can deploy it without having to redeploy everything else.

It does have a certain management effort associated with it, however so does deploying code via other means such as XPOs. One can't deploy a role via XPO if it is dependant on something that is not in the XPO.

I'd be very interested to get some of the other guys in this conversation perspective on this."

What are you thoughts on that? Do you have any BP how to handle the development across several models?

Waldemar

*This post is locked for comments

I have the same question (0)

All responses (4)

Answers (3)

Verified answer

Florian Hopfner 2,466 on at

Like (1)

Report
Copy link

Link copied!

We keep all customizations for a customer in one model, but we do not use the default layer model but create our own. This allows us to give the model a meaningful name, enables versioning and it also allows us to check for "lost" objects that were not added to the correct model. We keep a separate model for our development tools, these also help us to keep the customizations in the right model (basically we expanded the development projects with a model information; each time a development project is opened, the correct model is selected). For projects with a lot of security customization where the security development tool is used, we use a separate model for that, too (mainly because the SDT contains so many best practice deviations and we want to check the customer customizations for BP deviations without the noise from the SDT). The model with the development tools and the SDT are also checked in an isolated system before they are used in other projects.

Managing dependencies: Basically we try to minimize dependencies between models as much as possible. That means mostly using event handlers as much as possible, sometimes we go to great lengths to use an event handler, even if the alternative would be much easier. The few dependencies that remain are thoroughly documented so we know how to handle the missing dependencies if the model is used on its own.

Was this reply helpful? Yes No
Verified answer

Rachit 4,015 User Group Leader on at

Like (1)

Report
Copy link

Link copied!

Hi Waldemar,

Adding my bit to good details by FH-Inway.

Ideally models were introduced so that multiple solutions can reside on same layer side by side. The advantage is that we can easily install latest releases of these products without much efforts as compared to previous versions of AX where we might be ending up in code merge exercise due to other solutions present in the system.

I see an interesting point in your question on how you manage models for solution provider, vendor and inhouse development. In this case best practise is that solutions these should be on a complete different layer for example if you use a solution form an ISV then it goes into a model on ISV layer. Any customizations from your vendor normally goes in a model on VAR layer and any development done by a clients development team should go on CUS layer. So the advantage of models here is that if you have multiple ISV solutions installed on different models on ISV layer then it is easy to install fixes coming for a particular solution, but if you have customizations in higher layer then code conflicts needs to be resolved.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!

Guys, thank you for the input.

The biggest convern I have, when parnters or end users have several models and they develop within all of them in one environment. Because in most cases they are being tested separately. The idea is good: to keep separate solutions or kinds of development (code development, security, reporting) separately. But the reality is that you cannot rely that all the developers will understand the dependencies and always develop in the right layer. I think it is a descision on Development Lead or Architect level to control who is developing what in which model and at least have statical checks in AOT when you can't afford to test the models separately.

You mention it above too. So I am just highlighting what is the biggest p**n in the *ss for me.

Was this reply helpful? Yes No
Verified answer

Jonathan Halland 11,310 on at

Like (1)

Report
Copy link

Link copied!

Hi Waldemar

As an addition to the original comments of mine posted here. I would note we do try and create different models (for customers) based off the simple question of how would we like to deploy the solutions. I.E. Would we like to deploy all customisations at once or are there logical groupings without too many interdependencies that we can deploy separately. Hence the models that I suggested.

Regards

Was this reply helpful? Yes No