Last post Sep 07, 2010 10:07 AM by DigiMortal
Sep 05, 2010 07:17 AM|noobzor|LINK
I'm currently developing a 3-tier Architecture right Now. It consists of DataAccess Layer, Business Object Layer(sub class/project of business logic), Business Logic Layer and a Presentation Layer. All layers are very familiar to me but I'm having a problem
on Business Object Layer. I've designed all my Properties of my Business Object Layer in align with my Schema, meaning I didn't generate classes per table of my database. The dilemma is should I generate Business Object classes per table or should I shape
my business objects based on my schema? If I'm going on the per table basis some of the tables are not being shown on the Presentation Layer but rather used on my Store Procedures so that's one thing why I didn't go per table. Guys I need your suggestion.
Sep 05, 2010 08:07 AM|ketan_al|LINK
Please refer following
hope this helps
Sep 05, 2010 10:04 AM|riswadkarharshad|LINK
I am not sure much about Entity Framework but I think it is one of the newest ORM tools that may help you. Other forum memers may be able to comment more on it.
Also, you can try using strongly typed dataset.
I hope this helps.
Sep 05, 2010 10:11 AM|DigiMortal|LINK
When designing your BL focus on business logic and forget everything else. Persistence is topic you don't need to consider at BL layer. Just separate these things in your mind too. :) All three approaches to persistence are covered in the article
Mapping Objects to Relational Databases by Scott Ambler. Scott Ambler has also great book titled as
Building Object Applications That Work. I suggest you to read this book as it explains the topic more deeply.
Sep 05, 2010 11:58 AM|atconway|LINK
he dilemma is should I generate Business Object classes per table or should I shape my business objects based on my schema?
You should model your business objects based on their business and logical needs to conform to concepts like encapsulation and separation of concerns, and not necessarily in exact terms of how the tables in the database are modeled. The process of normalizing
a database which lends itself to the table design is not necessarily how you want to model the data in your objects as well. They are 2 different concepts and are like apples and oranges.
This reassembling of the database data or 'modeling/mapping' to the business objects are some of the power behind
Object Relational Mapping tools like the Entity Framework. Not suggesting you use it in your situation but just showing they have wrapped entire technologies around modeling the database data into their respective business entities. Many times we as
developers do this mapping and modeling of the data manually.
A good reason not to do a 1:1 object to table mapping would be in the case of a 'lookup' table with a 1:many relationship to another table in the database. Lets say their is a main table named: 'Customer' and then an 'Address' table with 1:many address',
and yet another table with address type: (home, busniess, work, etc) for that customer. You really don't need 3 separate objects to represent these tables. You will probably have a 'Customer' class and an 'Address' class. The Address class will contain
all of the address information including type, and then ultimately shows relationship to the Customer by being a collection property on the Customer object. If the 1:many type was less complex than an adress with multiple pieces of info like say a phone
number, then you wouldn;t even need a full blown class to represent it. You could just create a collection property on Customer with all of the customer's numbers. This is a abstract example and as you took an entire real database you would see many scenarios
where each table doesn't need its own class or busniess object. You are is some instances denormalizing the database data into meaningful single entities within your application that have a single business purpose.
Hope this helps a bit!
Sep 05, 2010 10:10 PM|noobzor|LINK
I got your point guys. I'm not planning to use EF but instead nHibernate. So I was right from my design at the beginning, I shouldn't map my Property Classes per table but combine them as One Entity depending on how they are being used is that correct?
Sep 06, 2010 02:12 AM|DigiMortal|LINK
Well, this is more like the question of balancing between performance and storage. There is no one and correct mapping strategy. You just have to take the one that fits for inheritance tree under question and decide what to do. Some simpler trees you can
keep in same table but for others you may consider the other options. If it is your first time to use deal with mappings then my suggestion is to try different strategies and measure how they work. Visual Studio has also database tools that are able to generate
random data to database so you can try out how your mapper works under different database size and load.
I suggest you to read
Agile Database Techniques by Scott Ambler. This book is targeted to developers and DBA-s and it helps to bridge the gap between them. This book also describes mapping strategies and it gives very good overview about considerations on database side. You
read my review about this book, maybe it helps you somehow to decide if this book is for you or not.
Sep 07, 2010 04:18 AM|Deleo|LINK
You should also throw a few thoughts to creation of DTOs Data Transfer Objects. Alot of times, business objects tend to have lots of properties and pherhaps methods, which is great for internal usage between layers. when those business objects need to go
outside the trusted environment, and through webservices or just to a html page, then you might need to reduce your business objects.
Take JSON for example. A webpage need to list items from a database using your 3-tier framework, but the webpage need to be asynchronous and uses JQuery for such. The main parser for this is JSON, although you can use XML, but JSON is preferable because
it has the least amount of overhead. Anyways, JSON parsing a regualre business object can be a pain, and there is a defualt limit of JSON packages as well. Here comes DTOs, where they are lightweight business object which is immutable and can easily traverse
layers and systems without much cost :)
Sep 07, 2010 10:07 AM|DigiMortal|LINK
Add these DTO-s to your model when they are needed, not right now because maybe they are needed. If you add maybe needed things to your model then your model will grow to monster that is very hard to manage and most of these complexities are created by features
you maybe need some day. But unfortunately the "some day" never comes because maintenance costs of system are too high....