Hi Allerseits,
wir werden in Kürze 365BC on Premises bei uns einsetzen. Da die Möglichkeit bestehen bleiben soll, evtl. später in die Cloud (SaaS) zu gehen, soll die Entwicklung von Anpassungen in Extensions gemacht werden, nichts in C/Side.
Wir sind drei Entwickler und entwickeln ausschlieĂźlich zur eigenen Nutzung. Bisher haben wir eine Entwicklungsdatenbank mit Nav3.6, auf der die Objekte angepasst wurden, bzw. neue Obbjekte entwickelt wurden. Wenn ein Entwickler ein Objekt bearbeitet, dann "sperrt" er es, indem er sein NamenskĂĽrzel in die Versionsliste hineinschreibt. Nach Test werden dann alle Objekte als .fob exportiert und dann in die Echt-Datenbank importiert. Das funktioniert soweit ganz gut und hat noch nie zu Problemen gefĂĽhrt, setzt allerdings ein gewisses MaĂź an Disziplin voraus.
Wir grĂĽbeln jetzt ĂĽber ein Konzept fĂĽr die Extension-Entwicklung.
Wie sollten wir die Extension(s) aufbauen ?
Ist es sinnvoll, eine große Extension für alles zu machen, also alle Anpassungen in einer einzigen Extension zu haben. Oder sollten wir besser einzelne Bereiche mit eigenen Extensions machen? Es wird sehr oft Überschneidungen zwischen den Bereichen geben, aber da kann man ja mit Dependencies arbeiten. Oder ist es gar vorstellbar, für jede erweiterte Table eine eigene Extension (Table und dazu gehörende Pages) zu machen. Auf diese Art findet jeder sofort die Quelle eines Feldes und braucht nicht zu grübeln, in welcher der Extensions ein Feld definiert wurde.
Wie gesagt, wir arbeiten nur für uns, brauchen also keine Rücksicht auf Vermarktungsfähigkeit etc. zu nehmen.