Repository and Unit of work pattern provides a clean way to access data using ORMs, keep all the data access logic in one central location and at the same time maintain the test-ablility of the application. Continue reading →
Avoid to put all the DB Objects into One Single Entity Model
Entity Model specifies a single unit of work, not all our database. If we have many database objects that are not connected to one another or these(log tables, objects used by batch processes,etc.) are not used at all. Hence these objects are consuming space in the memory and cause performance degrades. So try to make separate entity models of related database objects.
Will there be any issues adding a table without primary keys to a data model?
Every entity must have a key, even in the case where the entity maps to a view. When you use the Entity Designer to create or update a model, the classes that are generated inherit from EntityObject, which requires EntityKey. So, we have to have a primary key in the table to add it to the data model. Continue reading →
ORM (Object Relational Mapping) is basically an approach for storing data from domain/entity objects to relational database in an automated way without writing much code. A true ORM is independent of what database server we refer to, the code underlying ORM’s is database independent and can run with any database server having similar database with a structure needed by the application. ORM has 3 main parts: Entity class objects, Relational DB objects and information on how domain objects maps to relational DB objects, i.e., tables, views and storedprocedures.Continue reading →