ਇੱਕ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀ ਦੀ ਚੋਣ ਕਰਨਾ (ਭਾਗ 1)

ਹੈਲੋ, ਹੈਬਰ. ਇੱਕ ਨਵੇਂ ਕੋਰਸ ਸਟ੍ਰੀਮ ਲਈ ਦਾਖਲਾ ਇਸ ਸਮੇਂ OTUS 'ਤੇ ਖੁੱਲ੍ਹਾ ਹੈ "ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਟ". ਕੋਰਸ ਦੀ ਸ਼ੁਰੂਆਤ ਦੀ ਪੂਰਵ ਸੰਧਿਆ 'ਤੇ, ਮੈਂ ਤੁਹਾਡੇ ਨਾਲ ਆਪਣਾ ਅਸਲ ਲੇਖ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ।

ਜਾਣ ਪਛਾਣ

ਇੱਕ ਸੂਚਨਾ ਪ੍ਰਣਾਲੀ ਬਣਾਉਣ ਵੇਲੇ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀ ਦੀ ਚੋਣ ਬੁਨਿਆਦੀ ਤਕਨੀਕੀ ਫੈਸਲਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਲੇਖਾਂ ਦੀ ਇਸ ਲੜੀ ਵਿੱਚ, ਮੈਂ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਅਤੇ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹਾਂ ਕਿ ਕਿਹੜੀ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹੀ ਹੈ। ਪ੍ਰਸਤੁਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ, ਮੈਂ ਇੱਕ ਲਾਜ਼ੀਕਲ ਚੇਨ ਖਿੱਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ ਜੋ ਮੋਨੋਲਿਥਸ ਤੋਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਤੱਕ ਆਰਕੀਟੈਕਚਰਲ ਸਟਾਈਲ ਦੇ ਵਿਕਾਸ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।

ਇਤਿਹਾਸ ਦਾ ਇੱਕ ਬਿੱਟ

ਜੇਕਰ ਤੁਸੀਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪੁੱਛਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ: "ਸਾਨੂੰ ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?", ਤਾਂ ਤੁਹਾਨੂੰ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਜਵਾਬ ਮਿਲਣਗੇ। ਤੁਸੀਂ ਸੁਣੋਗੇ ਕਿ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਸਕੇਲੇਬਿਲਟੀ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੇ ਹਨ, ਕੋਡ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ, ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਈ ਵਾਰ ਤੁਸੀਂ ਸੁਣੋਗੇ ਕਿ ਉਹ ਤੁਹਾਨੂੰ "ਆਪਣੇ ਕੋਡ ਨੂੰ ਸਾਫ਼ ਕਰਨ" ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਆਉ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਉਭਾਰ ਦੇ ਪਿੱਛੇ ਮਕਸਦ ਨੂੰ ਸਮਝਣ ਲਈ ਇਤਿਹਾਸ ਨੂੰ ਦੇਖੀਏ।

ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, ਸਾਡੀ ਮੌਜੂਦਾ ਸਮਝ ਵਿੱਚ ਮਾਈਕ੍ਰੋਸੇਵਾਵਾਂ ਇਸ ਤਰ੍ਹਾਂ ਪੈਦਾ ਹੋਈਆਂ: 2011 ਵਿੱਚ, ਜੇਮਜ਼ ਲੇਵਿਸ, ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਦੇ ਕੰਮ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹੋਏ, ਇੱਕ ਨਵੇਂ "ਮਾਈਕ੍ਰੋ-ਐਪ" ਪੈਟਰਨ ਦੇ ਉਭਾਰ ਵੱਲ ਧਿਆਨ ਖਿੱਚਿਆ, ਜਿਸ ਨੇ SOA ਦੀ ਤੈਨਾਤੀ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਅਨੁਕੂਲ ਬਣਾਇਆ। ਸੇਵਾਵਾਂ। ਕੁਝ ਸਮੇਂ ਬਾਅਦ, 2012 ਵਿੱਚ, ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਸੰਮੇਲਨ ਵਿੱਚ, ਪੈਟਰਨ ਦਾ ਨਾਮ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਰੱਖਿਆ ਗਿਆ ਸੀ। ਇਸ ਤਰ੍ਹਾਂ, ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਦਾ ਸ਼ੁਰੂਆਤੀ ਟੀਚਾ ਬਦਨਾਮ ਨੂੰ ਸੁਧਾਰਨਾ ਸੀ ਮਾਰਕੀਟ ਕਰਨ ਦਾ ਸਮਾਂ.

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ 2015 ਵਿੱਚ ਹਾਈਪ ਵੇਵ 'ਤੇ ਸਨ। ਕੁਝ ਅਧਿਐਨਾਂ ਦੇ ਅਨੁਸਾਰ, ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਵਿਸ਼ੇ 'ਤੇ ਇੱਕ ਰਿਪੋਰਟ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਵੀ ਕਾਨਫਰੰਸ ਪੂਰੀ ਨਹੀਂ ਹੋਈ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਝ ਕਾਨਫਰੰਸਾਂ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਨੂੰ ਸਮਰਪਿਤ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ। ਅੱਜ-ਕੱਲ੍ਹ, ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟ ਇਸ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਜੇਕਰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਪੁਰਾਤਨ ਕੋਡ ਸ਼ਾਮਲ ਹਨ, ਤਾਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਪ੍ਰਵਾਸ ਸੰਭਵ ਤੌਰ 'ਤੇ ਸਰਗਰਮੀ ਨਾਲ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

ਉਪਰੋਕਤ ਸਭ ਦੇ ਬਾਵਜੂਦ, ਬਹੁਤ ਘੱਟ ਡਿਵੈਲਪਰ ਅਜੇ ਵੀ "ਮਾਈਕ੍ਰੋਸਰਵਿਸ" ਦੀ ਧਾਰਨਾ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹਨ। ਪਰ ਅਸੀਂ ਇਸ ਬਾਰੇ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ ਗੱਲ ਕਰਾਂਗੇ ...

ਮੋਨੋਲਿਥ

ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀ ਜੋ ਮਾਈਕ੍ਰੋਸਰਵਿਸਾਂ ਦੇ ਉਲਟ ਹੈ ਮੋਨੋਲਿਥ (ਜਾਂ ਆਲ-ਇਨ-ਵਨ) ਹੈ। ਇਹ ਦੱਸਣ ਦਾ ਸ਼ਾਇਦ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ ਕਿ ਮੋਨੋਲਿਥ ਕੀ ਹੈ, ਇਸ ਲਈ ਮੈਂ ਤੁਰੰਤ ਇਸ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀ ਦੇ ਨੁਕਸਾਨਾਂ ਦੀ ਸੂਚੀ ਬਣਾਵਾਂਗਾ, ਜਿਸ ਨੇ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀਆਂ ਦੇ ਹੋਰ ਵਿਕਾਸ ਦੀ ਸ਼ੁਰੂਆਤ ਕੀਤੀ: ਆਕਾਰ, ਕਨੈਕਟੀਵਿਟੀ, ਡਿਪਲਾਇਮੈਂਟ, ਸਕੇਲੇਬਿਲਟੀ, ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਕਠੋਰਤਾ। ਹੇਠਾਂ ਮੈਂ ਹਰੇਕ ਕਮੀ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦੇਖਣ ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਦਾ ਹਾਂ।

ਦਾ ਆਕਾਰ

ਮੋਨੋਲਿਥ ਬਹੁਤ ਵੱਡਾ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਬਹੁਤ ਵੱਡੇ ਡੇਟਾਬੇਸ ਨਾਲ ਸੰਚਾਰ ਕਰਦਾ ਹੈ. ਐਪਲੀਕੇਸ਼ਨ ਬਹੁਤ ਵੱਡੀ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿ ਇੱਕ ਡਿਵੈਲਪਰ ਨੂੰ ਬਿਲਕੁਲ ਸਮਝ ਨਹੀਂ ਆਉਂਦਾ। ਸਿਰਫ਼ ਉਹ ਲੋਕ ਜਿਨ੍ਹਾਂ ਨੇ ਇਸ ਕੋਡ 'ਤੇ ਕੰਮ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਬਿਤਾਇਆ ਹੈ, ਉਹ ਮੋਨੋਲਿਥ ਨਾਲ ਵਧੀਆ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲੇ ਮੋਨੋਲਿਥ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਬਿਤਾਉਣਗੇ ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ ਹੈ ਕਿ ਉਹ ਇਸਦਾ ਪਤਾ ਲਗਾ ਲੈਣਗੇ। ਆਮ ਤੌਰ 'ਤੇ, ਮੋਨੋਲੀਥ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਹਮੇਸ਼ਾ ਕੁਝ "ਸ਼ਰਤ" ਸੀਨੀਅਰ ਹੁੰਦਾ ਹੈ ਜੋ ਮੋਨੋਲੀਥ ਨੂੰ ਘੱਟ ਜਾਂ ਘੱਟ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਦਾ ਹੈ ਅਤੇ ਡੇਢ ਸਾਲ ਦੇ ਅੰਦਰ ਦੂਜੇ ਨਵੇਂ ਵਿਕਾਸਕਾਰਾਂ ਦੇ ਹੱਥਾਂ ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਅਜਿਹੇ ਸ਼ਰਤੀਆ ਸੀਨੀਅਰ ਦੀ ਅਸਫਲਤਾ ਦਾ ਇੱਕ ਸਿੰਗਲ ਬਿੰਦੂ ਹੈ, ਅਤੇ ਉਸਦੇ ਜਾਣ ਨਾਲ ਮੋਨੋਲੀਥ ਦੀ ਮੌਤ ਹੋ ਸਕਦੀ ਹੈ.

ਕਨੈਕਟਨੈਸ

ਮੋਨੋਲਿਥ "ਚੱਕੜ ਦੀ ਇੱਕ ਵੱਡੀ ਗੇਂਦ" ਹੈ, ਜਿਸ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਅਣਪਛਾਤੇ ਨਤੀਜੇ ਲੈ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਥਾਂ 'ਤੇ ਤਬਦੀਲੀਆਂ ਕਰਕੇ, ਤੁਸੀਂ ਦੂਜੀ ਥਾਂ 'ਤੇ ਮੋਨੋਲਿਥ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹੋ (ਉਹੀ "ਤੁਸੀਂ ਆਪਣਾ ਕੰਨ ਖੁਰਚਿਆ, *@ ਡਿੱਗ ਗਿਆ")। ਇਹ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਹੈ ਕਿ ਮੋਨੋਲਿਥ ਦੇ ਹਿੱਸੇ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਅਤੇ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਗੈਰ-ਸਪੱਸ਼ਟ ਰਿਸ਼ਤੇ ਹਨ।

ਤੈਨਾਤੀ

ਇੱਕ ਮੋਨੋਲਿਥ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ, ਇਸਦੇ ਭਾਗਾਂ ਵਿਚਕਾਰ ਗੁੰਝਲਦਾਰ ਸਬੰਧਾਂ ਦੇ ਕਾਰਨ, ਇਸਦੀ ਆਪਣੀ ਰੀਤੀ ਨਾਲ ਇੱਕ ਲੰਮੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਅਜਿਹੀ ਰਸਮ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਅਤੇ "ਮੌਖਿਕ ਤੌਰ 'ਤੇ" ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਸਕੇਲੇਬਿਲਟੀ

ਮੋਨੋਲਿਥ ਮੋਡੀਊਲ ਵਿੱਚ ਵਿਰੋਧੀ ਸਰੋਤ ਲੋੜਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਜਿਸ ਲਈ ਹਾਰਡਵੇਅਰ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਸਮਝੌਤਾ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਮੋਨੋਲਿਥ ਹੈ ਜਿਸ ਵਿੱਚ ਸੇਵਾਵਾਂ A ਅਤੇ B ਸ਼ਾਮਲ ਹਨ। ਸੇਵਾ A ਹਾਰਡ ਡਰਾਈਵ ਦੇ ਆਕਾਰ ਦੀ ਮੰਗ ਕਰ ਰਹੀ ਹੈ, ਅਤੇ ਸੇਵਾ B RAM ਦੀ ਮੰਗ ਕਰ ਰਹੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਜਾਂ ਤਾਂ ਉਹ ਮਸ਼ੀਨ ਜਿਸ 'ਤੇ ਮੋਨੋਲਿਥ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਨੂੰ ਦੋਵਾਂ ਸੇਵਾਵਾਂ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਨੂੰ ਦਸਤੀ, ਨਕਲੀ ਤੌਰ 'ਤੇ ਸੇਵਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਅਯੋਗ ਕਰਨਾ ਹੋਵੇਗਾ।

ਇੱਕ ਹੋਰ ਉਦਾਹਰਨ (ਵਧੇਰੇ ਕਲਾਸਿਕ): ਸੇਵਾ A ਸੇਵਾ B ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪ੍ਰਸਿੱਧ ਹੈ, ਇਸਲਈ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇੱਥੇ 100 ਸੇਵਾਵਾਂ A, ਅਤੇ 10 ਸੇਵਾਵਾਂ B ਹੋਣ। ਦੁਬਾਰਾ, ਦੋ ਵਿਕਲਪ: ਜਾਂ ਤਾਂ ਅਸੀਂ 100 ਪੂਰੇ ਮੋਨੋਲਿਥਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਦੇ ਹਾਂ, ਜਾਂ ਫਿਰ ਕੁਝ 'ਤੇ। ਸੇਵਾਵਾਂ B ਨੂੰ ਹੱਥੀਂ ਅਯੋਗ ਕਰਨਾ ਹੋਵੇਗਾ।

ਭਰੋਸੇਯੋਗਤਾ

ਕਿਉਂਕਿ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਇਕੱਠੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਜੇਕਰ ਮੋਨੋਲਿਥ ਡਿੱਗਦਾ ਹੈ, ਤਾਂ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਇੱਕੋ ਸਮੇਂ ਡਿੱਗ ਜਾਂਦੀਆਂ ਹਨ। ਵਾਸਤਵ ਵਿੱਚ, ਇਹ ਇੰਨਾ ਬੁਰਾ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ, ਘੱਟੋ ਘੱਟ ਇੱਕ ਵੰਡੇ ਸਿਸਟਮ ਵਿੱਚ ਕੋਈ ਅੰਸ਼ਕ ਅਸਫਲਤਾਵਾਂ ਨਹੀਂ ਹੋਣਗੀਆਂ, ਪਰ ਦੂਜੇ ਪਾਸੇ, ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਇੱਕ ਬੱਗ ਦੇ ਕਾਰਨ ਜੋ ਕਿ 0.001% ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਤੁਸੀਂ ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਗੁਆ ਸਕਦੇ ਹੋ. ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੇ.

ਜੜਤਾ

ਮੋਨੋਲਿਥ ਦੇ ਆਕਾਰ ਦੇ ਕਾਰਨ, ਨਵੀਂ ਤਕਨੀਕਾਂ ਵੱਲ ਸਵਿਚ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ. ਨਤੀਜੇ ਵਜੋਂ, ਉਸ ਬਹੁਤ ਸ਼ਰਤੀਆ ਸੀਨੀਅਰ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ ਇੱਕ ਵੱਖਰਾ ਕੰਮ ਜਾਪਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਚੁਣਿਆ ਗਿਆ ਤਕਨਾਲੋਜੀ ਸਟੈਕ ਇੱਕ ਬਲਾਕ ਬਣ ਸਕਦਾ ਹੈ ਜੋ ਉਤਪਾਦ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾਉਂਦਾ ਹੈ।

ਸਿੱਟਾ

ਅਗਲੀ ਵਾਰ ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ ਕਿ ਕਿਵੇਂ ਲੋਕਾਂ ਨੇ ਕੰਪੋਨੈਂਟਸ ਅਤੇ SOA ਵਿੱਚ ਜਾ ਕੇ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ।

ਹੋਰ ਪੜ੍ਹੋ:

• SQL ਸਰਵਰ ORDER BY ਤੋਂ ਬਿਨਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਕ੍ਰਮਬੱਧ ਕਰਨ ਦੀ ਗਰੰਟੀ ਕਿਉਂ ਨਹੀਂ ਦਿੰਦਾ
• ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕਾਂ ਲਈ ਆਰਕੀਟੈਕਚਰ: ਕਿਸ ਨੂੰ ਕਿਸ ਹੁਨਰ ਦੀ ਲੋੜ ਹੈ?

ਸਰੋਤ: www.habr.com