4 ms·

We've taken the view that the server side code and the client side UI are two different applications and should be developed as such. We write all the server s

by steverb 16y ago

We've taken the view that the server side code and the client side UI are two different applications and should be developed as such. We write all the server side stuff as "REST-like" web services and then use whatever makes sense for the UI, whether that is javascript, html emitted from the server, action-script or native binaries. Separation of concerns.

hbrundage 16y ago
The concerns aren't separate, thats the whole point! The validation and view logic is shared in "both" applications as you put it, so we either have to duplicate code or try and only put it in one place. This doesn't work or requires monumental effort, hence the whole post.
- steverb 16y ago
  They are separate. Yes, the UI and the service both validate the data, but they do it for different reasons. One is concerned with the user experience, and the other is concerned with data validity. There may be some functional duplication there, but they are separate concerns. The service validates to make sure that the data it is dealing with is safe and isn't going to corrupt something. The UI validates input to make sure that the service won't reject it so that the user doesn't have to deal with inconvenience of making a round trip to the server, or having to remember what a valid value for a field is. If you're not feeling up to making things easy for your users you can always throw all the data at the service and wait for it to tell you why the data is invalid. You don't HAVE to validate the data twice.
  - jamesgeck0 16y ago
    As a user interface shishya, I agree completely. As a developer, I still have to write code that validates the data twice and possibly deal with validation failures in two different ways. Further, I have to make sure that both checks are using the same criteria for validation and keep them in sync if requirements change. This seems less than ideal.
- aaronblohowiak 16y ago
  In my experience, validation logic is either trivially represented by a struct (could be a json structure, which is easily shared) or requires some form of I/O. In the latter case, it is usually easier to just handle this on the server side. On the former case, I agree that a simple validation library has yet to emerge as the One True Way to Validate.
- T-R 16y ago
  Out of curiosity, if your validation methods (written in the server-side language) don't have environment specific side effects, couldn't you compile them to Javascript for use by client-side code (using LLVM or something)? Or does that not work very well in practice?

by steverb 16y ago

hbrundage 16y ago

The concerns aren't separate, thats the whole point! The validation and view logic is shared in "both" applications as you put it, so we either have to duplicate code or try and only put it in one place. This doesn't work or requires monumental effort, hence the whole post.

steverb 16y ago
They are separate. Yes, the UI and the service both validate the data, but they do it for different reasons. One is concerned with the user experience, and the other is concerned with data validity. There may be some functional duplication there, but they are separate concerns. The service validates to make sure that the data it is dealing with is safe and isn't going to corrupt something. The UI validates input to make sure that the service won't reject it so that the user doesn't have to deal with inconvenience of making a round trip to the server, or having to remember what a valid value for a field is. If you're not feeling up to making things easy for your users you can always throw all the data at the service and wait for it to tell you why the data is invalid. You don't HAVE to validate the data twice.
- jamesgeck0 16y ago
  As a user interface shishya, I agree completely. As a developer, I still have to write code that validates the data twice and possibly deal with validation failures in two different ways. Further, I have to make sure that both checks are using the same criteria for validation and keep them in sync if requirements change. This seems less than ideal.
aaronblohowiak 16y ago
In my experience, validation logic is either trivially represented by a struct (could be a json structure, which is easily shared) or requires some form of I/O. In the latter case, it is usually easier to just handle this on the server side. On the former case, I agree that a simple validation library has yet to emerge as the One True Way to Validate.
T-R 16y ago
Out of curiosity, if your validation methods (written in the server-side language) don't have environment specific side effects, couldn't you compile them to Javascript for use by client-side code (using LLVM or something)? Or does that not work very well in practice?