Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Object-Relational Mapping - Taking the Horror Out of Data Access : Page 3

What are the benefits of using object relational mapping as persistence mechanism rather than .NET DataSets? Real-world use shows that developers who choose to work with persistent objects make more robust, scalable and maintainable software. By using object relational mapping you can still access data by connecting directly to the RDBMS, unlike choosing an OODBMS. There is a lot to be gained by using O/R mapping technology, and this article just talks about this.


advertisement

5. Fitting the O/R DAL into your N-Tier application
The O/R DAL slips logically right on top of the database. This means that you encapsulate any CRUD operations that you might have coded in SPROCs. I say logically because if the DB is placed on a separate server you would physically deploy the O/R DAL components on the same server as your business logic components. The reason for this physical partitioning is that the overhead of marshalling objects over a network is substantial. The SQL statements that are sent between the O/R DAL and the DB is much more chunky and better suited for network traffic.

Note that you should avoid coding business logic in SPROCs or the O/R DAL, such as automatically calculating taxes or rebates. The reason is that this is part of the business logic, not the data access. All decisions that are made by the business should be confined to the business logic layer. If the business rule is likely to be changed frequently, or contains variables such as interest rates or taxes, they should be out broken in a manner that is easy to update, such as using VBA, ASP-scripting or application preference objects that are stored in the database.




fig 4. The components of the O/R DAL are physically deployed on the same server as the components that access it. If the UI partly accesses the O/R DAL directly, it too should be deployed on the same physical server.

This architecture allows later partitioning of the database on several machines. The O/R DAL mapping can be updated accordingly and suddenly you have a database that scales out, albeit with some natural limitations.

Get all the benefits of .NET typed datasets and more
To those who haven’t yet switched to .NET it is notable that once you have created the O/R DAL, even if it is a simple one, you basically have a .NET typed dataset. If you implement data caching, it mimics the disconnected feature of the .NET dataset. If you have implemented inheritance in VB6, you will also improve your future migration to VB.NET where OO-features such as inheritance is rudimentary.

A VB6 code example
This is some sample code from a business component in VB6. The business method accesses a fully featured O/R DAL and for the sake of this example we use the API generated by Pragmatier Data Tier Builder.

Public Sub OrderItemsInShoppingBasket(ByVal CustomerID As Long) Dim Customer As Customer Dim Order As Order Dim OrderLine As OrderLine Dim BasketItem As BasketItem 'Fetch the customer Set Customer = ObjectFactory.GetCustomer(CustomerID) 'Create a new order(by sending True to the second 'parameter, called "Create") Set Order = ObjectFactory.GetOrder(, True) 'set the customer of the order to our customer Set Order.Customer = Customer 'Iterate through all the basket items 'in the customer's shopping basket For Each BasketItem In Customer.ShoppingBasket.GetAllBasketItems



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date