One Solution vs Multiple Solutions

Classic Servoy
1

We are in the planning stages of migrating to Servoy.

Currently we have 90+ FileMaker files facilitating a highly relational system that supports processes for more than one dozen departments. We will be implementing our Servoy solution one department at a time over the next year+ while maintaining the other departments’ functions in FileMaker. :shock:

We see two routes:

  1. design a single, integrated servoy solution
  2. design a servoy solution for each department

Should we go with choice #2 and design a solution for each department, all solutions will point to one mySQL database.

Each department has completely distinct processes. While many departments might need access to data in the Student table, they need to see it in their unique way. So we would provide access within their solution via forms, methods, etc. A department would never use another department’s solution. And we don’t forsee that the various solutions would talk to eachother (except in the sense that they all point to the same database).

Any insight into the implications of this decision?

~ Tara

2

Use option 2!, why:
-solution are smaller, faster download
-solution using the same tables is no problem at all when running on same Servoy Server (data notification/locks works across solutions)
-using controller.addFoundSetFilterParam makes distinct views for different departments possible
-Servoy 2.5 will have support to load another solution as module in the current solution (to prevent duplication of functionality), but since your departement have “distinct processes” this might not be relevant for you yet.

3

tara:

  1. design a single, integrated servoy solution
  2. design a servoy solution for each department

…Any insight into the implications of this decision?

~ Tara

Although, option 1 is a great way to go if you have similar processes in the whole of the combined solutions AND if you are on a local network and there is not too much WAN connectivity. The “slowness” factor won’t be much of an issue if you control the network. Plus, although I won’t argue that solutions are smaller and faster to download, once they are, they are cached and will take less time to load.

As Jan mentions, using controller.addFoundSetFilterParam works in smaller solutions, but it also works in larger solutions where you combine it with the use of the security commands. Coming into the system as a specific user or part of a specific group means I can optionally control the results provided by the database.

Advantages to going with #1 are you can share code resources for common tasks. For example, you can create a generic search routine where you pass it parameters of which data providers to search and with which data. This means your search routine can be used across all your subapplications.

Unless your applications are truly DISTINCT from each other, such as the difference between a construction application for managing the building of houses and a pet grooming shop solution, then there will likely be overlap when it comes to the code and what your solution does.

If you do have a good number of various subapplications within one general area, such as an education application that provides services from managing attendance to printing student ID cards then integrating will afford you much more “code leverage”.

The disadvantage you are going to find in Servoy, as with FileMaker, is that the level of attention given to organization and facilitating easy maintenence is going to be a HIGH priority. Things can get out of control if you don’t apply a strong standards model for your own development - at least in larger applications.

From the sounds of it 90+ database systems (probably files) is a scary thing to manage. But my preference is to keep similar types of systems within one solution. I’ll suffer the “first time” intital load of Servoy in favor of being able to “solution hop” within the one solution that addresses a common area.

Just my 2 cents.

report Boeing.pdf (1.95 MB)

4

From the sounds of it 90+ database systems (probably files) is a scary thing to manage. But my preference is to keep similar types of systems within one solution. I’ll suffer the “first time” intital load of Servoy in favor of being able to “solution hop” within the one solution that addresses a common area.

I fully agree here.
It’s a real pain having to go through x solutions to edit code that should be managed in one place.

5

Appreciate the dialog here, these are great considerations.

Would the new feature in 2.5 that Jan Blok spoke of assist with needing to replicate code across solutions?

~ Tara

6

tara:
Would the new feature in 2.5 that Jan Blok spoke of assist with needing to replicate code across solutions?

I think it does if for example a planner solution is build in can be used within other solutions as module

DialogsBeforeClickBtn2.png
DialogsBeforeClickBtn2.png681×429 25.2 KB