Skip to main content
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
Source Link

Sending data over the wire to an API Is, I think, one of the key drivers of an ADM/POCO style approach to programming (see my question : http://programmers.stackexchange.com/questions/283725/https://softwareengineering.stackexchange.com/questions/283725/ where i touch on some of the same points)

If you take the OOP route, you are faced with the problems of serializing a model which jealously guards its data and then creating a similar model on the server side from that data which may need maybe of the same basic functions, but all the best practice guides (for good reason) warn against using the same model on both sides of the service.

The ADM route makes the whole thing simpler, but there is a danger here that as the functionality of the service becomes complex, your simple procedural approach will result in 'bad' code, futhermore, there is a temptation for this style to spread to the application side of the interface.

However, I do think you can have the best of two worlds here. With the service you cant get around the fact that you are programming a function which takes a data struct as a parameter and making your program match this fact is the best thing to do.

As you can see in my example though, there's no reason not to make the service itself follow OOP within the restraint of 'you must receive and return a struct'

On the app side the restriction of 'some methods are not run on this machine' are harder to deal with. You can inject the service into the model and then have model.method() calling the service, but this will lead to some very contrived code in my opinion.

Or you can use the ADM approach of calling the methods on the serviceclient objects passing in your struct like models. Again this non OOP approach matches the reality of the situation, whilst enabling you to keep the rest of your code sensible

Sending data over the wire to an API Is, I think, one of the key drivers of an ADM/POCO style approach to programming (see my question : http://programmers.stackexchange.com/questions/283725/ where i touch on some of the same points)

If you take the OOP route, you are faced with the problems of serializing a model which jealously guards its data and then creating a similar model on the server side from that data which may need maybe of the same basic functions, but all the best practice guides (for good reason) warn against using the same model on both sides of the service.

The ADM route makes the whole thing simpler, but there is a danger here that as the functionality of the service becomes complex, your simple procedural approach will result in 'bad' code, futhermore, there is a temptation for this style to spread to the application side of the interface.

However, I do think you can have the best of two worlds here. With the service you cant get around the fact that you are programming a function which takes a data struct as a parameter and making your program match this fact is the best thing to do.

As you can see in my example though, there's no reason not to make the service itself follow OOP within the restraint of 'you must receive and return a struct'

On the app side the restriction of 'some methods are not run on this machine' are harder to deal with. You can inject the service into the model and then have model.method() calling the service, but this will lead to some very contrived code in my opinion.

Or you can use the ADM approach of calling the methods on the serviceclient objects passing in your struct like models. Again this non OOP approach matches the reality of the situation, whilst enabling you to keep the rest of your code sensible

Sending data over the wire to an API Is, I think, one of the key drivers of an ADM/POCO style approach to programming (see my question : https://softwareengineering.stackexchange.com/questions/283725/ where i touch on some of the same points)

If you take the OOP route, you are faced with the problems of serializing a model which jealously guards its data and then creating a similar model on the server side from that data which may need maybe of the same basic functions, but all the best practice guides (for good reason) warn against using the same model on both sides of the service.

The ADM route makes the whole thing simpler, but there is a danger here that as the functionality of the service becomes complex, your simple procedural approach will result in 'bad' code, futhermore, there is a temptation for this style to spread to the application side of the interface.

However, I do think you can have the best of two worlds here. With the service you cant get around the fact that you are programming a function which takes a data struct as a parameter and making your program match this fact is the best thing to do.

As you can see in my example though, there's no reason not to make the service itself follow OOP within the restraint of 'you must receive and return a struct'

On the app side the restriction of 'some methods are not run on this machine' are harder to deal with. You can inject the service into the model and then have model.method() calling the service, but this will lead to some very contrived code in my opinion.

Or you can use the ADM approach of calling the methods on the serviceclient objects passing in your struct like models. Again this non OOP approach matches the reality of the situation, whilst enabling you to keep the rest of your code sensible

Source Link
Ewan
  • 79.8k
  • 5
  • 83
  • 179

Sending data over the wire to an API Is, I think, one of the key drivers of an ADM/POCO style approach to programming (see my question : http://programmers.stackexchange.com/questions/283725/ where i touch on some of the same points)

If you take the OOP route, you are faced with the problems of serializing a model which jealously guards its data and then creating a similar model on the server side from that data which may need maybe of the same basic functions, but all the best practice guides (for good reason) warn against using the same model on both sides of the service.

The ADM route makes the whole thing simpler, but there is a danger here that as the functionality of the service becomes complex, your simple procedural approach will result in 'bad' code, futhermore, there is a temptation for this style to spread to the application side of the interface.

However, I do think you can have the best of two worlds here. With the service you cant get around the fact that you are programming a function which takes a data struct as a parameter and making your program match this fact is the best thing to do.

As you can see in my example though, there's no reason not to make the service itself follow OOP within the restraint of 'you must receive and return a struct'

On the app side the restriction of 'some methods are not run on this machine' are harder to deal with. You can inject the service into the model and then have model.method() calling the service, but this will lead to some very contrived code in my opinion.

Or you can use the ADM approach of calling the methods on the serviceclient objects passing in your struct like models. Again this non OOP approach matches the reality of the situation, whilst enabling you to keep the rest of your code sensible