Is there ever likely to be the option, to imp...

Is there ever likely to be the option, to implement polymorphic dependency injection via interfaces, that can be implemented by multiple different tables that follow that interfaceโ€™s structure?

I have built a CRM in Appsheet that is managing an increasing number of business activites in my business, and I am concerned that there are way too many logic loops based on queries between tables, to maintain the app long term, as things change and grow.

Going forward, I would like to refactor the app, so that there are a lot less conditional expressions, and I can encapsulate the state of each recordโ€“i.e. I donโ€™t want my calculated rows to be changing in unpredictable ways, as things get more complexly interelated across tables.

Has anyone gone down this track of trying to do something like SOLID object oriented design, in Appsheet?

1 16 539
16 REPLIES 16

@Stephen_Mattison I have 37 tables in the app and growingโ€ฆ Many of the properties of the records in each table are dependent on the state of related records in other tables. So a change in a record or design in one table can have unforseen effects in other tables. You see this as an error message sometimes, but there are errors that appsheet does not know to check for as there is no unit testing capacity on Appsheet. Eg. Each record in my Timetrack table has a required dependency on a record in each of the following tables:

Staff

Client

Calendar Entry

Service Booking

Service Booking Detail

Contractor Invoice and

Payment Request And each Timetrack record has many records in the tables

Action and

Image And that is just a list of the dependencies for one of my tables. Can you see any possibility one day that I make a change to one thing and then lose 12hrs repairing the app? Makes me scared of changing things and leads to app rot. Soon (hopefully not too soon) we will need to move to a code centric platform like .net so we can refactor the app to be more robust. Very grateful to be able to prototype it all in appsheet though!

I donโ€™t fully understand what you are asking here but why should there be a concern about the number of logic loops based on queries between tables as long as there are no cycles in the queries and no race conditions? Is the thinking that queries may be syntactically correct but could become semantically incorrect due to some obscure change down the road thus causing some rows to change unpredictably?

A future change in one table may cause unpredictable and unwanted changes in other tables, or break things. Google โ€œSOLID principles of OOPโ€. Cheers, D.

The biggest reason I want to minimise conditional expressions is that it takes a long time now to sync the app, and when I make a change in one place I donโ€™t want to have to make 100 other changes to fix the side-effectsโ€“it is taking too long now.

@David_Ackling-Jones Wish I had something for you here bro.

I have a feeling the AS dudes would tell you to split this monster into several Apps.

As a multiple business Owner, I like to cram as much as I can into one App, so I can just live in there, but your description sounds hairy!

It would be neat to see an image of your Spec View for this App, where we can see how everything is connected.

The very cool new Search View might be great for you.

Have you played with that yet?

Pretty powerful!

It seems to act like a โ€œSlice on the flyโ€.

Cool @Stephen_Mattison I wil check out the Search View, I have not been aware of that yet. Here is my spec view, it is a bit insane.

Capturespec.JPG drive.google.com

@David_Ackling-Jones You might need to ask to be added to beta of Search View, which AS just now changed to โ€œAssistantโ€ View.

If you have access, youโ€™ll see it available when you go to add a new View.

@David_Ackling-Jones, it sounds like what you need is two things: (a) the ability to define data constraints โ€” to handle the data dependencies you have and (b) the ability to change column names and have that seamlessly modify all the expressions.

Iโ€™m not really sure you need polymorphism and OO design. That usually does not fit very well with database persistence (despite a lot of efforts over time).

Hi @David_Ackling-Jones, it is difficult to do true object-oriented design in a data-centric platform. Tough in SQL, tough in AppSheet. AppSheet already has the concept of entities (equivalent of classes in OOP). We could, in principle, grow AppSheet to have the notion of private and public columns (properties) and private and public actions (methods). Also in theory, we could augment the data model to cover concepts like inheritance, polymorphism, etc. From the history of database systems, this is very similar to what object-oriented databases tried to do in the 90s and failed to get market traction โ€” there were relatively few data-centric applications that needed it.

That would be brilliant Praveen!!

To be clear David, I am not saying we will do this. In fact, Iโ€™m pretty sure we will not do it in the foreseeable future (for precisely the reason that the OO-DB vendors failed in the 90s โ€” it appears that the vast majority of data-centric business apps donโ€™t really need the richer OOP mechanisms).

Iโ€™m just saying I think I understand what you are asking for.

It would be amazing to have an abstract table that only had calculated fields, and could be implemented by more than one table.

Thanks so much for responding Praveen. Your app is brilliant.

@David_Ackling-Jones

Can you share (lots) more about one or two of your logic loops and/or conditional expressions that you are concerned with becoming a problem in the future?

What is the nature of your business?

It would help to understand more about the issues here and make suggestions.

I am starting to implement a type of Polymorhphism into my app by referencing Slices rather than tables in my ref columns, but it is a bit messy to say the least.

Eg. My โ€œPersonโ€ table has a column [PersonType] enum which can = Client,

= FamilyMember, or = Staff. I have a slice for each [PersonType] that makes different columns public depending on the [PersonType]. e.g. Only the โ€œPerson_Staffโ€ slice exposes the column Person[StaffID]

In the โ€œPersonโ€ table, I set each property on each column (e.g. RequiredIf) with a conditional experession depending on the [PersonType] e.g. the RequiredIF and ShowIf properties of Person[StaffID] are if

[PersonType]=Staff

So this is a way to have several different types of Person behave and compose themselves differently, without creating a different entity to hold them.

The messy thing is the proliferation of conditional expressions required to manage this patternโ€“If we could just be able to implement an abstract Table with multiple concrete tables that would be AWESOME.

Really keen to share ideas with others who are making apps that are getting a bit too large for comfort, and are using patterns to manage the chaos.

Michuli
Participant II

Man, I have the same fear one day my apps could become unmaintainable. This would be nice though: "(b) the ability to change column names and have that seamlessly modify all the expressions." 

Top Labels in this Space