|
What are entity objects really? Why some insist that they should match the database tables? Are they insane?
Entity objects are classes that encapsulate the business model, including rules, data, relationships, but definitely not persistence behavior, for items that are used in your business application. For example, entity objects can represent
- The logical structure of the business, such as product lines, departments, sales, and regions.
- Business documents, such as invoices, change orders, and service requests
- Physical items, such as warehouses, employees, and equipment.
|
|
The wrong way: Entity object to database table one to one mapping (LinQ to SQL). Yes LinQ to SQL is the wrong way; Instead use a visual tool, maintain and test your database access tier without writing SQL or ADO.Net; definitely no horrific object query language experiences either, not necessary.
When an entity object resembles a database table then it simply follows the database structure and schema whenever it changes or when the entity object needs more attributes then the database table has to change. A database schema is simply designed to hold the data based on the well defined relationships and a business entity object simply represents business data that may come and (most of the time) it does from multiple physical tables. If I need specific columns from specific tables that are related to each other, why do I have to have all of these objects that represent my data tables in memory? When a query brings back a large number of data, this has no cost? Can we assume that reflection (used to populate entity objects) has no impact on performance? We surely say not.
The better way: Orasis Mapping Studio. The Visual data access tier builder. Stop Coding boring code and do not mess with object query languages that will take you forever and slow performance as well. You can do better now.
In a typical system design, use case requirements drive data CRUD operations to the database schema and SQL is the language that databases speak. Given a visual tool that allows the developer to visualize the database tables and graphically build the SQL query, the next step is as simple as associating an entity object with this SQL. This association boils down to some ADO.Net code and Orasis Mapping Studio allows the developer to simply make this association with a few mouse clicks.
|
Whether your entity object comes from a DLL or whether you want Orasis Studio to create it for you, or whether you need to map n levels deep in your object entity, Orasis gives you the power to do it visually and very easy.
Maintainability of your entity objects. Your entities, where are they used and how fast do they perform in a transaction? No you do not need to write any code to find out and no need for any searches across files to find object queries either.
In a typical data access tier you have entity objects participating in your database transactions. Orasis Mapping Studio allows you to know at any time how these entity objects are used. You can do this by:
- Simply select a Mapping and see the entity object that it uses. If you want to change it simply right button click and reassign a new entity object to your query. Visually remap it however it makes sense to your business.
- Select the types tab and see all of your imported object entities as well as the ones that were auto created by Orasis (Managed).
- Select a mapping, right button click and say test. See the time that it takes to populate your entity object list and optimize accordingly.
|