Dear all.
Since Telerik proclaims "code-only" is the island of happiness and I disagree I'd like to start a CONSTRUCTIVE discussion on alternative solutions for some issues.
How do you solve the following issues?
1. Create a good looking documentaion of your domain model.
2. Generate boiler plate code (OData, WCF, implement several interfaces, naming conventions, ...).
3. Take care of views and stored procedures.
To be honest: I like ONE thing about their decision: No GAC installation of DataAccess.
Hopefully we find a solution to combine the benefits of the "disgusting legacy" DataAccess and the "shiny" new DataAccess.
Kind regards
Bernd
2 Answers, 1 is accepted
Rank 1
Not data access dev, but can share how my team deals with some of this.
[quote]Bernd said:
1. Create a good looking documentaion of your domain model.
[/quote]
Depends on what you want. Any .net code documenter can work, such as sharpdoc http://sharpdox.de/en/ or sandcastle https://sandcastle.codeplex.com/. Fancy visual layouts can be generated by Visual Studio or Resharper as well.
[quote]Bernd said:
2. Generate boiler plate code (OData, WCF, implement several interfaces, naming conventions, ...).
[/quote]
Code generation is something I want too. :/ You might just be best off coming up with your own convention based solutions, at least then you have control of the code.
[quote]Bernd said:
3. Take care of views and stored procedures.
[/quote]
DA still handles arbitrary stored procs the same way on the 'low level' api. http://docs.telerik.com/data-access/developers-guide/low-level-ado-api/executing-stored-procedures/data-access-tasks-adonet-execute-stored-procedure.
If you want nicer more oop style c# methods thats kinda the generator problem again unfortuately.
You can map the results to persistent types that you have mapped: http://docs.telerik.com/data-access/developers-guide/low-level-ado-api/materializing-objects/dev-guide-adoapi-materialize-persistent-types or just some arbitrary object that matches the values by name: http://docs.telerik.com/data-access/developers-guide/low-level-ado-api/materializing-objects/dev-guide-adoapi-materialize-nonpersistent-types
Rank 2
Not data access dev, but can share how my team deals with some of this.
[quote]Bernd said:
1. Create a good looking documentaion of your domain model.
[/quote]
[/quote]
Hi George.
Thank you for your answer.
[quote]George said:
Depends on what you want. Any .net code documenter can work, such as sharpdoc http://sharpdox.de/en/ or sandcastle https://sandcastle.codeplex.com/. Fancy visual layouts can be generated by Visual Studio or Resharper as well.
[/quote]
Sandcastle isn't developed any more. I'll have alook into Sharpdox. Thanks for the hint.
[quote]George said:
[quote]Bernd said:
2. Generate boiler plate code (OData, WCF, implement several interfaces, naming conventions, ...).
[/quote]
Code generation is something I want too. :/ You might just be best off coming up with your own convention based solutions, at least then you have control of the code.
[quote]Bernd said:
3. Take care of views and stored procedures.
[/quote]
DA still handles arbitrary stored procs the same way on the 'low level' api. http://docs.telerik.com/data-access/developers-guide/low-level-ado-api/executing-stored-procedures/data-access-tasks-adonet-execute-stored-procedure.
If you want nicer more oop style c# methods thats kinda the generator problem again unfortuately.
[/quote]