Fluent API - Sean Stevens

okay welcome everybody I'm Sean Stevens this presentation today is on using the fluent API specifically we're using the fluent API to configure our entity mappings with any framework code first so I'm a little background for those of you that don't really know what that is entity framework is a created by Microsoft it's a that's basically like a library that we can use as c-sharp developers to interact with the database and just a little history on code first entity framework it basically it'll give you two two ways of interacting with your database the original more traditional way is that you would create your database and then and you'd use any framework to kind of auto generate classes in your code that you would use to interact with the database code first is the opposite approach so you would go in create some classes in your code and it would automatically generate database tables that you would work with that with that so a better little example here in your data model you create a class and it would create this table here based on what you put in here now that's pretty straightforward the problem is there's a lot of things you would want to do in your database that are more advanced than just this simple little class here and so that is what that's what we use the fluent API for or data annotations is you know you could go into sequel manager make a really complicated database well how are you gonna do that if you're just writing your data classes how are you going to get that kind of functionality out of your database so fluid fluent API generally speaking is a method of writing codes so some of you that have used link before are kind of familiar with the syntax yet it's it's a syntax where you're going to if you look here we have this dot has key this is kind of the format of a fluent API is that you have dot and then some really descriptive work like has or required or using includes that's really in a broader sense what fluent a fluent API is in this specific context we're talking about how we use the fluent API when we're doing code first and trying to generate the database the way that we want it to for what we're going to work on fluent API and any framework six we could start looking at it by in your database context you have this on model creating and so for a pretty simple application you can go in and just put in these configurations right here directly into the our model creating if you don't have that many and we're going to start there because we're just going to start looking at some examples and we'll get into some more complicated examples as we go along okay so there's really three areas that I'm going to talk about in this presentation we're gonna look at entity properties entity relationships and entity table inheritance I'm going to get into you - it's all three of these areas in this presentation and hopefully this will give you a good introduction to fluent API and how you're going to use it alright so with this presentation I've created an example solution and it's available for download and we'll put this link in the YouTube video so you can go check out and download this this solution file it's got several different projects in here for each of the three areas that we're looking at properties relationships and inheritance I've created two two projects one shows an example of how you would do these mappings using data annotations and the other one shows a mapping using the fluent API and so you can you see how you would do it in each way and you'll also begin to understand we're just using data annotations is a little limiting there's a lot of functionality that only exists with the fluent API so not necessarily it depends on how complex your change is with the entity code first we have concept of migrations which you know if you were to say just go in and add a field that's pretty straightforward to just it'll just go in and add that field for you sometimes as we're developing a more complex application there there can be some pretty dramatic changes that that you would need to regenerate your database entirely but one one thing you can do to help mitigate that is that when when you're migrating your database each time it'll keep track of all the changes in these migration files and you can actually go in and edit those and customize them a little bit to make a smoother transition especially if you in a production environment you don't want to blow away the database so you could you can customize those migrations so that it's it's going to be a safer transition okay so entity properties we're gonna look at creating teh how we create tables how we create seed data and how we access that data so to start out with with the properties examples we've got a pretty straightforward schema here I mean it's not there's nothing exciting here we're not really concerned with the relationships at this point we're mostly just going to look at the different data types that we've put in there because when you create your model it's it's it's pretty simplified you know a string is just going to be just just created as n VAR Carmack's I mean there's these kinds of things going on and so we're going to want to be able to customize these a specific way so in the project that I've set up I've got a property project and I have a property map and so for these two projects I've got them pretty simple you can see it's just got a couple of classes here in the model and this is an example of run here and for the sake of simplicity as I go through these examples I don't want to put too much code in here so I've kind of just tried to strip it down just the most important things that I wanted to show you so like I said before the the examples of these mappings that I'm going to show you these in the project files when you go through it you can see they're all in this on model creating and you'll see that there's like you know 20 of them are all in there it gets to be cumbersome to have that many thrown in there but we'll address that a little bit later okay so creating the tables we'll start here with one kind of one of the kind of basic things of setting up and identifying what is a primary key now one thing about entity framework code first is that you're going to design your model and any framework is going to kind of guess what you meant to do when it goes to create the database it's going to make its best guess some things are pretty straightforward but it's going to try to make its best guess you can see at the bottom down here there's there's kind of a convention here that if you take a field and you either name it ID or have the class name followed by ID it's gonna assume that you met for that to be the primary key but for whatever reason for for your business requirements you may not want that to be the ID for that table so here I have one it's musician key and we want that to be the primary key so with data annotations you would just put this key right here that if you're doing data annotations in fluent API yeah in your modern model builder you would use this syntax which is the fluent API center next to say dot has key you can specify exactly which fields you want to be the key yeah the next one that God says model builder dot has key in another field are you going to get an exception if you do that nobody will come to that we'll come to that with the composite keys yeah yeah so that just adds that field to the primary key yeah I'll show you an example here in just a little bit of setting up that composite key because you are gonna want to do that sometimes yeah the identity fields yeah yeah we'll get it to that too hopefully let's see how we do one time okay so switching off the identity or numeric keys so you can see here this field we've created a track ID it's following that convention so it's just going to naturally assume that we want this to be an auto increment laying primary key but we don't want to for the purpose of our of our models so here you if you're doing a data annotation you would put this tag here specify that you do not want this to auto increment this field and with fluent API you use this syntax the dot property and dot has database-generated option going generated annotation or has database-generated option those indicate the batterer key you still have to do the previous annotation or method that we didn't form previous slide in addition to these well either in this case it's going to assume this is the key because it has ID on it but yes yes you would even combine these and use this this is just turning off the identity so this is still the key of the table but it's a it would may be a situation where you're you're gonna have your own IDs that you're going to put in then you don't want to rely on that identity auto-increment for that ID you're going to define the ID yeah and that's a lot of fun too okay so here we have the composite key and like you said when you're doing it with the data annotation you have to put the order to put the ID in there the order ID on fluent ID that our fluent API that order is determined by the order that you put them here when you configure those those two fields to be to be the key and one thing you might start noticing here is that and for some of you that have worked with this before the data annotations can start to make your code a little bit confusing you start getting a lot of those in there it can become a little bit confusing I prefer personally to use the fluent API as often as I can because you can see up here in the model this is this code is much cleaner and we've got kind of a separation of concerns here where where we just focus on creating those field names and the data types and then we use the fluent API to to set up these types of things okay configuring your index on a property data annotation it's pretty straightforward here you can you can also see here that when you're using the fluent API you can just keep coding dot something because you may have many on a given field and many many things that you're you're going to want to do with that feel to get it get it customized so that you your database comes out exactly as you intended it to this one's pretty forward setting the column size it defaults to max on a lot of these like I said any framework is gonna try to guess at what you meant to do but here we can implicitly say this is how we want this field to be defining database this one column name the datatype and optimistic concurrency when you're setting these up you can see again I've got several on here kind of a similar thing with the data annotations is that you can put a lot of these on here if you put too many there could be conflicting there could be problems for for entity framework so you want to be a little bit careful make sure that you're you know exactly what you're doing with these so these types are database specific at this point right yes so you you're now saying this is a sequel server database versus Oracle or whatever right yeah you're specifying implicitly what what that is for the database column size and changing the data table there's a different example of changing the data type again you can see that with fluent API we've just thrown a bunch of these on there and we've in this case this is a fixed length length field of three it's an example how we do that okay so property precision this is going to be one of those areas where we don't have a way to do that with data annotations and you can only do that with the fluent API and this brings me to another point which is if you if you want to do all of these configurations and data annotations there is a way that you can do it when you run into something like this what you can do is you can create a custom data annotation and in your custom data annotation you're going to use the fluent API you would do this setting the precision for a decimal field and then you could have only data annotations but at some point with some of this functionality you're going to have to use the fluent API somewhere so we'd be in that custom data annotation is where where you would use your fluent API configuring the not and all column here I have a string and I want it to be acquired which is not the default a way the enemy framework would build up but you can force it to and same with setting a null column for an integer saying what senator to be knowable and again you can see here we have the separation of concerns where we just build our model pretty straightforward and then in any framework we put this kind of customization specifying not to map a property so in this case we for whatever reason want to have this field in our model and we use this in our code but we don't want it to go to the database I mean it could be calling some third-party web servers or something else for that value and it's it's not something that we want to have a database field for it so we tell tell any framework to not create that field in the database complex types I'm not sure how many of you have worked with that before but you can use complex types with both data annotations and fluent API it's it's kind of an abstraction of you you have a class and you don't necessarily want to have a table for that class but you have other classes you're going to create tables for and they're going to include those fields it's kind of a way of saying you know if you if you got to feel like a date field or something like that and you want several of your classes to use that in there you wouldn't be generating a database table for that but all of your other other entities are going to include those fields in in their table when it's generated and this is another example of specifying that a specific class is a complex type this is how you with data annotations simply use this tag here oops and then in the model builder we just specify that that class is a complex type okay so we've been through several examples of how we're going to modify our properties when we generate the table so the next is seed data for these properties so inside of your migrations configuration file you're going to have what when you start creating migrations you're going to have this seed method here and in this seed method you can begin to put in data that for example if you're building an application and right out of the box you're going to need a couple of users you've got some data that when you start start going here you need you need some kind of sample data in the database to work with so in this case the most important thing to think about when it comes to properties is making sure that the data that you're using is the right type that it matches the type that you've configured you can see here on this length property I'm using this format to put in the length it's a it's a decimal field and integers strings getting getting the date format exactly correct like that's that's kind of the main thing you have to worry about when you're seeding this data is to make sure that they text correct because you said you can even how many decimals really matter does it rounded up does it run the down can you use like floor or ceiling or does it just do like up to five and enough it's however you can commit but again without that's an example of one where that doesn't exist with the data annotations you have to use the fluid API to do that one okay so accessing the data inside if you download the sample solution I've created a console app here that it has an example for each one of these different projects that that will access the data from there and as we get a little further along this you're going to see we're going to get into more and more examples of where you can do something in fluent API but you can't do it with the data annotations and so it's pretty straightforward you can see that I'm also using this dot syntax to include these entities that are related to the banns entity and it's pretty straightforward to iterate through these objects and and dump out the data I have an example here of when you run this of how that is going to present this data into the console app okay so the next section we're going to talk about is we're going to get into more of the relationships between the tables this is this is where the floor AP has going to start become a little more powerful some of those properties most most of them you can do with the data annotations it's when we get into more complex relationships and and the next section table in here and is where we're going to start to see where some of the power of this comes in so again we're gonna I'm gonna show you how to create the tables create the seed data and access the data now here one thing I've mentioned before is that this on model create where you're putting your fluent API I mean if you could start to have so many of them in there it's not the right place to keep them all a smaller application that's that's fine to just put them in there in line like you did but you're going to want to start to abstract that out at a certain point and so we have the ability that we can create these separate mapping files each one having its own configuration for that giving entity I have this mapping directory that I've created in my projects and there's a separate file for each one this is an example of the account entity and how we set a map up is just a little bit simpler than what we had before but it's still using that dot syntax that has required customer with many accounts it's still still really straightforward one of the great things about fluent API is that it's it's much more readable it's much more it's easier to read it and instantly understand what it is exactly that is that maybe if you have some kind of you know you know in the old days you just write a method to do some kind of filtering and you'd be jumping around in the code trying to figure out what exactly does this piece do but here with many I mean it's much more straightforward to understand what what it is that you're you're trying to do all right so creating the tables here this first one is one to zero or one relationship we're setting out between a customer and an address this is an example of we're gonna have a customer record and we may or may not have an address record attached to that customer and so how we set this up with the data annotation you're going to set that foreign key on the address idea we're going to set the address ID to be is going to be mapped to the customer ID and with fluent API we're just going to do that that has optional address with a required customer so that this allows us to have a customer and it may or may not have an address record it's not being forced to have an address record and the other version of that would be a one-to-one which is we are forcing that relationship to exist that if you're going to have a customer record you have to have a contact record also when we get into seeing the data I'll talk a little bit more about how you get that data in there then you create the customer first to the contact first how do you do that if they both have to exist so we'll talk about that so the customer in the contact the relationship is pretty similar to the 1 to 0 or 1 but we have required that it's required for a contact to have a customer and here we have this has required contact with required principal customer so again get it getting this relationship set up is is possible with both the data annotations and the fluent API now one one side note I have here is that a one to one force relationship is not really possible in sequel server where this is being enforced is in encode in your entity framework it's going to create that one-to-one relationship and force that relationship to exist yeah yeah doesn't sense the real and in your database doesn't care I mean if you were to go in and just insert records the databases okay the one two mini so we have a customer that may have mini accounts again this is a pretty straightforward relationship when we set this up it's similar to the previous syntax when we set up the foreign key I mean the account has a foreign key to the customer ID and here we have the has required customer with many accounts and when you're reading these and you're looking at this code for the first time it's pretty easy to instantly understand what is exactly this logic was trying to do technically a zero to many of the application level or a one this would have to be a one committee you know zero yes there has to be a one yes yes there has to be a one okay so many to many this is where things get start to get a little bit interesting because like I said before and any framework is gonna try to guess what it is you meant to do so I try to do the best that it can so we send up a set up a minute in any relationship we have we have an entity for customer and we have an entity for branch and we want to say that we could have many customers attached to many different branches and so when we set up this relationship you can see that the the set up in our model is almost exactly this I means pretty much exactly the same and so what happens is there's going to be a third third table that's created when we do this that that keeps the mapping of customers to branches yes exactly now when you're using the data annotations we don't have a way to specify anything more than just that that relationship exists so what every framework will do is it will create this table with a table name that it wants to use and it's going to name these fields the way that it wants to name them you don't have a lot of there and that can become a problem if according to your business rules are something that you need to have specific fields so this the fluent API mapping here allows us to give that third table a specific name that we want it to be and name the IDS that go in there a specific ID and so you can see here this Haida soups and I switched these to be customer branch instead of branch customer and then I give it IDs that I like to use in my system okay lefty or righty key doesn't matter yes yes it does seems like it starts with this is a mapping in the customer map so you started with customers Jovie branches and customers for that book look at his house and then many branches yes okay table splitting so in the case of table splitting what we want to do is that we're gonna have we're gonna have two separate entities okay we have a director at a department but we want them to go into one table and they these entities have a relationship that exists between them and you can see here that we have this we've defined here table Department we're forcing this director based on the relationship that's set up with the foreign key to go into the same table let's take a look at that again Department ID a department name employee ID and director name you can see that the department ID is part of the department entity and when we do something yeah yeah as a foreign key to Department and here we set the inside inside of the department mapping we specify that it has a director and the principal is the department and it's forcing it to go to table department and the director we have to do a mapping as well and tell it what the foreign key is and tell it which table to go into the next thing is kind of the opposite of that this is where we are going to do entity splitting meaning we have one entity but we want to save it into two separate tables certain so we want to save certain fields into certain tables so here I've got a regional office is really what the entity is and it's got these fields here it's got its ID a name administrator and phone number but I want to specify that these two fields regional office ID they're mainly you're going to have the office ID in both of them they will both have that ID in them but I want to say the office name is going to go into regional office table the administrator and the phone number are going to go into the office detail and this can get when I've used this before this can be really helpful when you have entities that have a lot of fields and so you know you may have your first one the main the main one may just have a couple of fields to help you identify what it is and the other one may have the other different fields and so that when you're working with this and code and passing it around a lot it can make it a lot easier to deal with that again this is an example something that we have available to us in fluent API but does not exist in the data annotations okay so the seed data for these relationships the seed data on this can get a little bit tricky I was like I talked about before if you have a required relationship between one and another which one you create first one one way that I like to use to get around that issue is in my seed data here um kind of outside identity I'm just going to go ahead and create it like a list of addresses a list of contacts a list of accounts and a list of branches so I've created these kind of outside of entity just so that I have that data available and then here when I go ahead and do this add or update when I'm actually interacting with the database oh I'm actually going to insert this I have a complete customer record and I've gone and specified the branches and accounts and addresses of contacts that I've already created and it keeps this a little bit cleaner now you could just put all of that configuration right into this new customer it'd be pretty big and pretty pretty hard to read and also where you can run into trouble is that see I've created this branch branch one I may want to use this in several of these different customers in in the in the actual project there's there there's many of them in there so I have a lot for customer one a lot for customer two a lot for customer three just for this demonstration to show you I just put in the okay and on the table splitting again we have a similar thing where we want to have directors already configured outside of entity but then when we do the add or update I can reference those that I've created there when I'm actually putting in the entity for Department C and then on entity splitting it's this is this is a little more straightforward because when we insert these our entity can just have all those fields there and then any framers going to split them into the right table that they're going to go into so that one's pretty straightforward okay accessing the data again this is going to be similar to what we looked at before we have the dot includes syntax which is again perform a fluent API it's not the enemy code for a saloon API but this this allows us to pretty clearly say okay here's it here's all of the other objects that I want that are associated with customers when I go to the database and get this data and then we can iterate through these objects to write out the data in this in this example of the customer with all of his other related entities I can dump out the data that's associated with that customer and then on the departments we have one department object with a director and so you can see that a department that a department we iterate through the list of departments and they have connection to the director with this kind of syntax Department director dot directory and then regional offices this one this one's also pretty straightforward when you wouldn't you get back that entity even though even though it's two separate tables we're just going to work with the one entity of regional offices and it has all the fields already in there there's nothing extra special that you have to do because it's stored in two separate tables some so you can see here kind of how I dump those dump that data out for the departments and for the regional offices okay so before we go on is there any questions about setting up those relationships am I just overwhelming you with boredom now we're going to look at in code I didn't put any funny pictures in here sorry about that let me drill down as I do some research for this presentation it's kind of spread out there there wasn't one good solid list I could find there were one or two sites that were helpful but the information wasn't organized and laid out like this it was really scattered around and you have to dig around and find and find it so um there's two two sites that I I've used to get this information I'll include those when we put the YouTube video up there I'll include I'll put the links to those two in there and that can help you I would say to get some good examples of how to do a specific thing that you want to the solution project that solution with the projects that I put together here is a pretty good resource I think it'll help you but yeah you can you can look for these things or like I said they're scattered around it's not clearly explained another another thing you'll find that I found is they'll come up with an example model let's say three or four tables and then they go through with examples and every single example is modifying that exact same model and that can be kind of cumbersome you say I want to see example these two things well you only have this one model and if either one of the eight of them so yeah I run into those same problems previously I was just using the data annotations when I was doing this and you run into those issues and and the fluent API will help you work through those that will bring break the database constraint now that will yeah that's that's gonna really gonna have to have the one sign up or else or else you have to change the relationship without any with the not required sure okay so table inheritance we're gonna take the relationships now I get a little bit more complicated on how we're going to set these relationships up again we're gonna I'm going to show you how to create the tables how to create the seed data and how to access the data the table inheritance okay so in our previous example inside of our own model create we started to get a lot of these mapping files set in there now you may have 50 mapped files so again you know what I have to manage that all the time that can be kind of cumbersome so in any framework six we can use this add from assembly and what will happen is it will automatically look through your code and find all those mapping configurations and include them so this is kind of when you have a lot of them this is going to make things easier for you I've got in this example I've got six different mapping files so there's not that many but like I said when you get into larger application do you not have a hundred in these miles and so it's going to make it a little bit easier to not have to manage putting all those in there and updating them every time you make a change but you keep it in the model model create configurations pair them in your own this will pick it up out of there I'm not sure about that we'd have to look we'd have to try and experiment and see if that is true and also yeah and this brings me to another point I'm not sure how many of you started working with the.net core or the enemy framework core yeah I'm doing some work with it and the it's it's a work in progress there's some there's some functionality that they have not put in there yet one thing that you will notice as you start working with it is that all of your API fluent API mappings have to just go into this on model creating there is not a way to create separate mapping files and reference them here there will be there will be but it's kind of low on their priority list right now there's other things that the developers are working on and that's kind of when the nice thing about that community is if you get into some of the blog posts is you get actual Microsoft developers in that like it's it's you know since this is open-source they're they're actively interacting with people who were he tried to use it and also another interesting thing is that I found that there's bug fixes being made by just regular people don't work for Microsoft there there are they're able to go in and make bug fixes for or what the core framework but yeah this this is one of the things that I ran into using entity framework or is that you have to just put all of your mappings right in this on model create but I'm you know I'm sure they'll come around on that and then another one is that they don't have a way to create seed data but that's not put into the migration there's no migration configuration file anymore and so that's again another thing that though they'll be working on and that functionality will be there it's just not there right now yeah you can specify exactly which libraries that you want to put into your application make it lighter and optimize it run faster so yeah like I said they have their own list of priorities of what's going to happen next and what things in the next year are going to be done and what's gonna take maybe two years to get done but there are workarounds there are there are ways to work around some of these things and as you search around you'll find them like I found some workarounds for the seed data I found some workarounds for this issue with the on model creating I wasn't very happy with them though so I put my mappings here for now but I you know over to overtime the resolve those issues I'm sure okay so table inheritance the first thing is creating the tables so in this example here we're going to look at the table per hierarchy inheritance so what is the table for hierarchy when we we have an entity in this case it's billing billing may have a couple different types of billing and in our example we have bank accounts and credit cards so between those two types of billing there are similar things between the two in this example we have owner and number they're both going to have owners and numbers of credit cards and bank accounts but they have different fields as well so for a bank account you're gonna have a bank name and the Swift for a credit card you're gonna have a card type and an expiration date so the idea here is that we want to use this inheritance here they inherit from the billing class bank accounts inherit from the billing class and credit cards inherit from the billing class so when we set these up in our in our model you can see that we don't have any data annotations here at all so why would we need to have this floon API what does it do them for us well you can see here that when you use this kind of inheritance it's going to create a in the data annotation example it's going to create this discriminator fields for us it throws all the fields into one table so all the different types will be in here so if you have a credit card record in here it's not gonna have a bank name in Swift those fields is just being all and if you have a bank account in here the expiration month an expiration year will be null yes yeah it's not normalized and your discriminator it's going to have a value of either a bank account or credit card that's how entity framework is just going to automatically set up this kind of table inheritance so with the fluent API that allows us to specify we can specify what we want that field name to be we don't want to be discriminated we wanted to be something specific that we want in this case billing type and then the values that go in there I I may want to put in a CH and CC instead of the class type name so that's where the fluent API allows us to set this up see it's got the building type field instead of discriminator field and if I had an example of the data that's inside which will look at the seed data a little bit later you'll see that it's using a CH and CC instead all right the next table inheritance that we have here is we have an employee and we have two types of employees we have accounting employees and we have marketing employees so in our example first name and last name accounting and marketing employees both both out those fields accounting accounting type of employees have a certification label level and a security level marketing has a coach name and total sales so in this example here we're establishing this relationship so that the type tables are broken out with normalize this a little bit the type tables are broken out and we have one central table that has the the fields that are the same and when we set this up with the data annotation we just specify that you can see that this inherits from employee and we want it to go into the employee accounting table and here it's from employee and we want it to go into employ marketing table these specific fields the mapping on the mapping side you have to do this you have to create an employee accounting mapping an employee marketing mapping and they just really just have that two table specifying which table that data is going to go into so the table per type is pretty straightforward but I've been using this a lot lately it's pretty powerful as opposed to that first method but you will not have run into reasons why you need that first method you have something like a lot of generic types of things in your database it can be able to be helpful for that plus more joints with more expensive correct but it's going to fill up that table with a lot more records and a lot a lot of em people problem yeah exactly all right so the table per concrete clocks this is kind of the other opposite end of the spectrum so what we're going to do is we have two types of customers we have online customers we have on-site customers so we create two separate tables and they have all the fields including duplicated fields so in this case customer ID first name and last name exist in both sets of tables okay so there is not a way to do this type of inheritance with the data annotations this is again something that's only available in the fluent API and so we set up our base class our base customer and again the setup of these in our model is is very similar to what we were doing before the difference being that we use this map syntax so that we can specify that customers of type online are going to go to this table and customers have type on-site we're going to go into this table so again it's it just it just depends on what your business rules are of your application on which of these types of table inheritance you might want to use and like you said there's trade-offs obviously I whichever way that you choose to use all right so the seed data for these you can see here that when I I create this billing of creating Billings billing entity records and when I do it I can specify whether it's a bank account or whether it's a credit card and I include the fields that are appropriate for that type and you can see that there's that on the billing ID that there's going to be one ID even though even though these are different types of billing objects that there's one central ID between the different types okay table per type all right it's very similar to the table per hierarchy and then also the table per concrete class will be very similar that we can use this same syntax for all three of these they're from our model point of view we were approaching it pretty similar from code well the difference is is how it's saved in the database and entities handled enough for us so we don't really have to worry about that when we create the C data okay accessing the data so we have a couple different options here in this first one what I'm doing is I'm just getting all the billing records and then I can check on is this a billing bank account or is this a billing credit card and based on that I can do something or you can see that I dumped out all of the information here with respective to what type it is which fields go with that type or you can get them individually like in this case I'm just getting I'm just getting bank accounts or I'm just getting credit cards I just want to get those types just straight out and do something with that data and in this case I get all the bank accounts and print them out or I get all the credit cards and top them though okay so next when we're getting on these are the table / okay next we're on the table for type so again I can just get all of the employees and I can as I as I interact through my employee records I can say is employee accounting or is employee marketing and I can do something with that data and with the similar kind of syntax so here I've never got all the employees and I've broken them out by accounting or marketing again I can get just the accounting employees records and do something with them or just get the marketing employee records and do something with them in this case I'm I'm dumping each of these out separately this and lastly again you can start to see that whichever approach that you've taken when you're when you're going through these with code if they're all similar like that the fact of how they're saved in the database has been extracted away from us it's not something you have to worry about anymore that's being handled by entity framework itself and whichever method you're using it's kind of as you're going through this code it's something you don't have to worry about this again get all the customers and I I can break out the online and the on-site from the full list of customers print them out or I can get just all the online customers and do something with them or I can get just all the on-site customers and do something with them okay so just to kind of wrap up we talked about the entity properties we talked about the entity relationships and we talked about the table inheritance and again if you want to go take a look at the solution that I've created that has these projects in them you can see all the examples of of how you would set these up using data annotations or using the fluent API and then it's just kind of a final note here there are there's a lot of other things you can do with the fluent API and code first that are kind of on the side of our example here that are not available in beta annotations so it's really it's you know I hope that this presentation that least gives you an introduction to this and you can as you're running into software problems and trying to figure out how to solve them you've you've kind of got in the back of your mind well there's the fluent API maybe I should look there and see if there's a way to solve this problem use math because I've created my data model and I don't like the way the tables coming up I want to do something else so okay so any other questions good all right

Channel: Stg Administrator

Views: 8,004

Keywords: #hangoutsonair, Hangouts On Air, #hoa

Id: IwcMd5YmcoQ

Length: 52min 41sec (3161 seconds)

Published: Wed Feb 08 2017