In this session I will show you how I used the Entity Framework Services to design and create an API servicing layer to expose back end data to partners. We will dive into using the Entity Framework (data layer), WCF Data Services (service layer), T4 templates (business entities), WCF Message Inspectors (security) and more.

1. Real World API Design Using The Entity Framework Services

3. dotNetDave Conference DVD! Packed full of: Videos of all sessions from 2010 & 2011(1)! Slide decks from 2011 & 2010! Demo projects from 2011 & 2010! David McCarter’s .NET interview Questions! Extras Conference Photos from 2010! Surprise videos! Book + DVD $25! Only $15!

4. Check Out Your Local User Groups! San Diego Cloud Computing User Group www.azureusergroup.com/group/sandiegoazureusergroup San Diego .NET Developers Group www.sddotnetdg.org San Diego .NET User Group www.sandiegodotnet.com San Diego SQL Server User Group www.sdsqlug.org

6. Overview

7. Current Problem Partner Company Data Store Internet All Data Stored in local Data Center Customers/ Partners do not have access to data No ability to create “add-ins” to application No ability to “upsell” products

8. Partner Company Data Store Internet Immediate access to the network data for partners Provide customers with an ever growing wealth of tools for extending application Marketing Exposure Handle billing and purchasing transactions with the end-user Business Proposition

9. Goals Make it easy to access data Access to data from any application Windows Web iPhone … Track Usage For billing Detect abuse

10. Goals Provide ability for different application types Visual Application Surface partner application inside of company application Data Application Allow data access to authorized customers Composite Application Combination of Visual and Data

11. Challenges Current database design Very Confusing Same data in multiple tables. Allow secure access to data App can only access a select number of services App can only access data for authorized customers Access data from multiple locations Some customers store data locally

12. Design

13. Database Issues Hundreds of tables. Tables can have hundreds of columns (some not used anymore) Same data is stored in different tables. Tables store multiple types of data. Primary data keys duplicated in almost every table. Too much expertise needed to understand database.

14. Database Solution Design model of how data should look, regardless of how it’s currently structured

15. Database Solution Use Views instead of Tables Allows creating data structures that make more sense, easier to use. Allows splitting/ combining of data from Tables. Allows renaming of columns that make data more understandable/ consistency. Use stored procedures to insert/ update data

16. Database Solution Use Entity Framework 4 to implement object model on top of Views Easy for developers to use/ understand Separate models by purpose Easier to deal with Re-use views in different models (sparingly) Remove properties that don’t make sense in model Insert/ updates only through “main” Entity Use POCO T4 template Easy to separate entities from data access Can add functionality/ business logic Smaller payloads across the wire

19. Exposing Data to Partners Expose services via HTTPs Use WCF Data Services Expose data via REST (JSON and AtomPub) Easy to expose Models One model per service Control Entity access using EntitySetAccessRule

20. Exposing Data to Partners Use WCF Data Services Limit number of records returned using EntitySetPageSize Prevent partners from access to clients that have not “enabled” the application Modify data coming into service using ChangeInterceptor’s Can also update date in multiple Entities

23. Security Limit partners access to data/ services Validate call is from authorized partner Using certificate or token Validate client Validate partner has access to service. Validate client/ app Validate app Validate app is active Validate app access to client

24. Security Use WCF Message Inspectors Intercept service call before it hits the service Different Message Inspectors for different types of services General services uses certification Client data services uses token Smaller than a certification Authentication done by calls to back-end Also used for logging partner usage data What they are hitting Payload sizes

27. Summary

28. Challenges EF does better with “properly” designed databases EF designer can easily screw up models (better in EF 4) WCF Data Services can be limiting Have to jump through a few hoops to have WCF Data Services to expose entities from a separate project Have to manually edit .svc files to use Message Inspectors

29. Challenges Bad REST Queries = Bad SQL Queries Demands more processing power on the web tier Majority of programmers have never used REST/ LINQ to Rest More of a challenge with other languages (mostly because samples are written in .NET 4)

30. Looking Forward Allow more write access to data Provide “batch” processing Faster data access on first hit Allow read/write access to Entity per app Create new database from cleaned up model (far in the future) Better configuration, security, logging and developer portal using third-party vendor