Dev303 Leap In Productivity With Linq And Entity Framework 4
•
0 recomendaciones•1,046 vistas
For TechEd ME attendees: DEV 303, wednesday 11am Dubai C One might ask, how can one be even more productive than with a DataGrid bounded with a DataSource? Is it even possible? It sure is possible! To me, being productive doesn’t just mean starting fast, but keeping a sustainable pace as things get more complex. This is what true productivity is all about. We’ll look at the evolution of design from Smart UI type of architecture (Rapid Application Development), 3 tier (Transaction Scripts) to Domain Driven design with rich domain models with behaviors. I will introduce the first few examples using Linq to SQL, and will take it to the finish line using the upcoming Entity Framework 4 and its POCO support.
Recomendados
Recomendados
Más contenido relacionado
Más de Ronald Widha
Más de Ronald Widha (7)
Último
Último (20)
Dev303 Leap In Productivity With Linq And Entity Framework 4
- 1. Dev303: Leap Ahead in Productivity with LINQ & Entity Framework Ronald Widha @RonaldWidhaTeam Lead Infusion Development
- 2. Required Slide Complete an evaluation on CommNet and enter to win an HTC HD2!
- 3. Agenda Pattern #1: Smart Client Pattern #2: 3 Tier Architecture Domain Driven Design Pattern #3: Domain Modelling Entity Data Model Entity Framework 4 Entity Framework 4 cool features (POCO, code only)
- 4. Presentation Tier Data Smart Client
- 5. Presentation Tier Business Data 3 Tier Architecture
- 6. Demo: RAD and 3 Tier
- 7. Domain Driven Design “an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.”
- 8. Domain Driven Design Tackling complexity How: Talk to the business! Focus on the core business domain Design system based on a model
- 9. The concept Entity & Value Objects Aggregate Roots Repositories Value Objects Value Objects Repository Aggregate Root Entity Entity Value Objects
- 10. Keep it in sync with reality Business rules change: REFACTOR! Names change: REFACTOR!
- 11. Presentation Tier Business Data Domain Models
- 12. Linq to Sql Isn’t flexible enough for domain modelling 1-1 table mapping Table per Hierarchy No provider model Awesome for data access
- 13. Entity Data Model An abstract conceptual model of data Based on Entity Relationship Model by Dr. Peter Chen (1976) Entities and Relationships Entity types Association types Navigation properties Sounds familiar??
- 14. The Entity Framework 4 The next layer up in the ADO.Net stack First product to implement EDM Entity Data Model design tools Strongly typed LINQ access Declarative mapping to the database The next version to Entity Framework 1 from .Net 3.5 Available in .Net 4.0
- 15. Demo: Domain Driven approach using Entity Framework
- 16. Full control Just basic POCO: Plain Old CLR Objects Persistence Ignorance Turn off code generation from EDMX
- 17. Demo: Domain Driven approach using Entity Framework POCO
- 18. POCO and Other EF Features Different ways of mapping: Table per class, Table per type, Table per hierarchy Mapping with stored procedures Explicit Loading ObjectContext.LoadProperty(someObject, x => x.property) Lazy Loading Property as virtual Uses proxy instance at runtime
- 19. Code-only design No model Metadata is inferred from classes Convention by Default Configuration Tweak configuration Create database at runtime
- 20. Last Notes Don’t take the demo as best practice There are a lot more to Domain Driven Design that what’s shown here There are a lot more we can do to improve the demo code (Unit of work!) EF4 is perfect to enable Domain Driven approach
- 22. Required Slide Speakers, TechEd 2010 is not producing a DVD. Please announce that attendees can access session recordings at TechEd Online. www.microsoft.com/teched Sessions On-Demand & Community www.microsoft.com/learning Microsoft Certification & Training Resources http://microsoft.com/technet Resources for IT Professionals Twitter @RonaldWidha http://blogs.msdn.com/adonet/ Resources for Developers Resources
Notas del editor
- Hi My name is Ronald Widha, team lead, infusionTwitterPlease don’t forget to fill up the assessment sheet, I’d love your feedback, especially praisesWelcome to “Leap Ahead in Productivity with Linq & Entity Framework”This a 300 level (advanced) talk, which assume you have some knowledge on entity framework, and general data access patterns
- So I’m sure all of you have built applications which interacts with database beforeSo leap in productivityHow can you be more productive than thisPerfect for rapid application developmentBut is it really productive?Productivity to me is more than just starting fastBut also to keep the same pace as the project goes more and more complex
- You have heard thisPresentation tierBusiness tier: these managers and services focused on the use cases. The implementation of the methods are normally calls to the data tierData tier: which in turn talks to the infrastructureIt’s data centric applicationA smart guy name Martin Fowler calls this: Transaction scripts.Because the business tier consists of transactional procedural script
- Each of the managers are reusableObject oriented? Yes Manager/Services are objectsWe have the data encapsulated as objectsBut why isn’t the behaviors of the object get attached to the object itself.For e.g I want to be able to say ron.friends.add(photographer)Without the behavior, photographer camera objects are just data wrappersWhat’s wrong with that?Throughout time, as business rules gets more complicated, these rules will be scattered everywhereAgain, our focus is to get productivity by Managing complexity
- What is it?2 books talks about this: Martin Fowler introduced the concept in his bookEric Evans covers the detail on How domain modelling can and should be done
- Tackling complexityHow?Talk to the businessGet the core business domain knowledge and apply that to the design of your applicationTry and get rid of any impedance mismatch between how the business view a problem,With how we the engineers solve the problem
- So again we want to focus on the domain. So we look for ways to represent these concepts in our system designEntity: an object in the domain model that is identified by its id. E.g same name, different id, different personValue objects: an object that doesn’t have any ID, and solely identified by its characteristics e.g if 2 address objects are the sameRepositories: a way to retreive entitiesAggregate roots: We want to be able to navigate from one entity to the nextPhotographer.cameras iterate through all the cameras owned by the photographerthe root entity where everything else is related to. The only one that has repositoryI have an address, I have a job, I’m speaking in a conference. Therefore I’m the aggregate root
- UI, Business Tier, Data AccessDomain Objects business objects with have behaviors You should be able to navigate from one domain objects to another by accessing its propertiesIt’s no longer data centric, you care about the business concepts. The domain knowledge
- 1-1 table mapping: doesn’t provide a flexible domain modellingCan’t hide the join table for the many to many relationshipOnce you have inheritance, it gets even trickier, linq to sql only support table per hierarchyAll that parent, child objects need to be stored into 1 tableNo provider model: if you don’t use sql server, you’re out of luckIt’s excellent tool for writng data centric application, but when you’re doing domain modell, you’re starting to push it to its limitsAnd if you don’t use any object relational mapping framework like linq to sql, and use t-sql, boy, it’s hard!-------Abstract concept above the data: entityRing a bell? Entities?It has relationshipsIt has navigation properties.What does that mean: you can navigate from parent entity to the childIf I want to get my camera’s manufacturer name, I don’t do inner joins between relational tableI don’t write queries using linq with where clausesWith navigation properties: Photographer.camera.manufacturer.name
- - Next layer up above data- It implements the Entity Data Model concept, which is compatible with Domain Driven mentalityIt has full design tools, and the experience is as rich as Linq to SQLIt has linq capabilitiesCan handle different kinds of mappings to the database, not just 1-1You can hide that join table if you wanted toYou can have differnet kinds of inheritance modelTable per hierarchy, table per type, table per classIf you want to know more you can talk to me afterwards at the speakers lounge
- At this point you might ask what is the difference between Entity Framework and Linq to SQLYes you can have more flexible mapping, but it’s still tightly coupled right?
- So this is the cool thing, unlike linq to sql, the class is all in your control.You can create Entities using just POCO: Plain Old CLR objects, in other words: normal .net object without any framework specific base classesThis is also known as Persistence IgnoranceEntities should not know about the infrastructure/databaseIt is just a domain model and that is it. Nothing more.The idea is, you should be able to switch between Entity Framework to any other data access technology if you want to.How to do that, turn off the code generationSo you have full control over the classThe mapping between the object and the EDMX will be based on conventionIt tries to match the property name with the model namePOCO Generatorhttp://visualstudiogallery.msdn.microsoft.com/en-us/23df0450-5677-4926-96cc-173d02752313
- Just like linq to sql, you can force to fetch related objects manually for optimizationJust like linq to sql, you can also leave it up to query related objects as it neededLoading the photographer class, will not have to load all the cameras until they are neededAll you have to do is mark the properties as virtualThe way it works, it replaces the property with a proxy class at runtimeSimilar way to how Nhibernate does it.Custom mapping, mapping with stored proc
- Before we end the session, I want you to check out the code only designIf you’re a hardcore code junky like me, and don’t like using the mouseDon’t care about the database and want to fully ignore the persistence layerEverything is convention basedIt uses the name of the property and match it with the column nameYou can tweak it as you go alongOn runtime you can check if the database existIf it’s not,You can just generate the database from the classA similar approach to Azure storage approach (for those who attended Tuesday’s session of Windows Azure). Check if table exist, create if it doesn’t
- Access session recordings at tech ed onlineMore videos about entity frameworkPDC09 walkthrough upcoming Entity Framework 4 featuresTwitterDon’t forget to fill up your Evaluation sheet