Thank you for contacting us.
Your concerns are understandable. We will give you our thoughts on the subject and address your concerns. However please keep in mind that since the approach to implementing the WCF services is highly dependent on the specifics of your scenario and it would have a huge impact on the development of your system we cannot give you a concrete answer about which would be best for your situation.
Generally the Service Wizard is designed to save development time and produce an extensible service layer. However if the scenario has very specific requirements that would need a very high level of customization, the benefit of automatically generated service layer may be outweighed by the ability to have complete control over the design and architecture of the services.
You can also consider combining the two approaches. You could start up by using the Service Wizard to generate the service layer and customize it to your liking. While repeatedly using the wizard as your application grows, you can evaluate whether doing so will become too troublesome in the future and decide whether to switch to manually extending and modifying your existing code.
Regarding the location of the generated files a
s you have seen currently the Service Wizard provides little control of where the files would be generated. Certainly separating the files in different projects and folders can help have a cleaner project structure. You could consider whether moving the generated files manually to the desired folders or projects would an acceptable workaround.
We also have a feature request
regarding this limitation at our Feedback Portal. We would like to invite you to vote for it and post any feedback you might have as doing so will help us prioritize its eventual implementation.
As for defining service contracts per view
or based on other criteria, depending on the scenario this could be helpful but it can also introduce complex service structure which could be needed in order to avoid repeating logic for exposing the same entities over several service contracts. If your scenario would benefit from organizing your services in this manner, coding them by hand could be the better approach.
I hope this helps. In case you have additional questions or need help, do not hesitate to get back to us.
OpenAccess ORM is now Telerik Data Access
. For more information on the new names, please, check out the Telerik Product Map