Hello again after a bit of delay.
Let's look at DataLibrary, the one containing the Entity Data Model, data methods and custom data types.
Below is the image of a custom data type to be used when querying for items in store:
It is a public class in it's own namespace (DataLibrary.Types.Store) containing properties that will hold data from Item entity representing store.Item data table. Interesting part is Details and Comments. I could've made those as two new classes and use them here. I decided to use built in types as they were enough to represent my data: list of strings for Details and dictionary of strings for Comments - key for title, value for comment.
Important note about creating custom data type classes: if you need a complex type for displaying data on a page from various joined data tables and no any extra data needed (data not binded to any table column for example), save time by NOT creating a type manually and then having to write complex linq query to fetch it from database. Use what is already available: SQL View. You can import views from database into entity framework, query them with linq to add some conditions or ordering and have data pronto.
Now let's look at the more interesting stuff - data methods. Below is the image of the public static Security class containing methods for operating on Security data located in security schema tables that holds data regarding users:
All methods are declared static so they can be used without instantiating the class. Static classes do not have a constructor but we could have a setter for eShopEntities instance to utilize Dependency Injection, a lot of buzz is about it these days. I don't do that and will rather instantiate eShopEntities object generated by the Entity Framework inside using statements inside our methods to work with database when needed. We are disposing of eShopEntities instance as soon as we get data from database, don't want it hanging around (it implements IDisposable interface so using statement will tell garbage collector to dispose of it as soon as we are done with it). These methods, I call them data methods as they work with data and they are located in DataLibrary, effectively make Stored Procedures in database obsolete. You do not need to have Linq inline with you business logic if you don't want to, and you don't want to except if you just need it in that one place, you can create methods that are reusable and respect DRY principle (don't repeat yourself). Feel free to download source code of the eShop website application and look around DataLibrary yourself.
Next is the WebLibrary, the code that runs it all, business logic layer.
In WebLibrary I will show you how to design and implement custom Forms Authentication with your own data stored in forms ticket (basically an encrypted cookie), connect that to Google Sign In so you can utilize Claims based authentication and how to implement Moneris Api. This will be divided over couple of posts.
As always, thank you for reading.
Let's look at DataLibrary, the one containing the Entity Data Model, data methods and custom data types.
Below is the image of a custom data type to be used when querying for items in store:
It is a public class in it's own namespace (DataLibrary.Types.Store) containing properties that will hold data from Item entity representing store.Item data table. Interesting part is Details and Comments. I could've made those as two new classes and use them here. I decided to use built in types as they were enough to represent my data: list of strings for Details and dictionary of strings for Comments - key for title, value for comment.
Important note about creating custom data type classes: if you need a complex type for displaying data on a page from various joined data tables and no any extra data needed (data not binded to any table column for example), save time by NOT creating a type manually and then having to write complex linq query to fetch it from database. Use what is already available: SQL View. You can import views from database into entity framework, query them with linq to add some conditions or ordering and have data pronto.
Now let's look at the more interesting stuff - data methods. Below is the image of the public static Security class containing methods for operating on Security data located in security schema tables that holds data regarding users:
All methods are declared static so they can be used without instantiating the class. Static classes do not have a constructor but we could have a setter for eShopEntities instance to utilize Dependency Injection, a lot of buzz is about it these days. I don't do that and will rather instantiate eShopEntities object generated by the Entity Framework inside using statements inside our methods to work with database when needed. We are disposing of eShopEntities instance as soon as we get data from database, don't want it hanging around (it implements IDisposable interface so using statement will tell garbage collector to dispose of it as soon as we are done with it). These methods, I call them data methods as they work with data and they are located in DataLibrary, effectively make Stored Procedures in database obsolete. You do not need to have Linq inline with you business logic if you don't want to, and you don't want to except if you just need it in that one place, you can create methods that are reusable and respect DRY principle (don't repeat yourself). Feel free to download source code of the eShop website application and look around DataLibrary yourself.
Next is the WebLibrary, the code that runs it all, business logic layer.
In WebLibrary I will show you how to design and implement custom Forms Authentication with your own data stored in forms ticket (basically an encrypted cookie), connect that to Google Sign In so you can utilize Claims based authentication and how to implement Moneris Api. This will be divided over couple of posts.
As always, thank you for reading.
