Class Design Help

Question

Hi all,

I have the following database tables to work with and i am sort of new to oop so i thought i'd ask here.

assignment
----------
id
person_id
assigned_address_id
position_id

person
----------
person_id
current_address_id
name
ssn
drivers_license

address
---------
id
address_number
address_street
address_city
address_state 
address_zip

position
---------
id
description
rate

I have created the following classes

Person Class
int? id
Address currentAddress
string Name
string ssn
string drivers_license

PersonAssignment Class
id
person_id
Address assignedAddress
Position assignedPosition 

Address Class
string address_number
string address_street
string address_city
string address_state 
int address_zip 

Position Class
int? id
string description
double payment_rate

I've also created Seprate Service Classes for each of the objects which access the Dal.Repository and perform crud methods on each of the objects. i.e.

PersonService Class
Update(Person p)
Insert(Person p)
GetListOfPeople()
GetPerson()

PersonAssignmentService Class
Update(PersonAssignment p)
Insert(PersonAssignment p)
GetListOfPeopleAssignments()
GetAssignment()

I also have Repositories for Each of the Objects

i.e.

PersonRepository Class
Update(PersonAssignment p)
Insert(PersonAssignment p)
GetListOfPeopleAssignments()
GetAssignment()

On my webpage which contains both a persons assignment and the persons personal details i find myself calling PersonService and PersonAssignmentService.

This just seems like a lot of work. Am i doing something wrong? Maybe there a more simple way to design something like this and i'm just not getting it.

Thanks for any help

Thanks

Answer 1

Database design and Classes can be sometimes difficult to critique and much of it really depends on your business rules and the type of transactions you have.

For starters I would not have a separate table for a person's address and I would not create any particular class that defines and Address.

I'm not sure what programming language you are using but it would probably be worth your time to check out ORM (Object relational mapping)

Answer 2

What you need to do is design and implement a data access layer:

http://rlacovara.blogspot.com/2009/02/high-performance-data-access-layer.html

The article is the best that I have seen so far in describing how you would write a data access layer. The author describes that the you need to create DTO (Data Transportation Objects) to move your data from the data access layer into the business layer (or into another layer where they can be converted to native application classes). He provides base classes and code to help you with Data Transportation Objects, code to populate the DTO, and code to save the DTO to the database.

There are three articles in the series, and I recommend reading the entire set.

Answer 3

I'm not 100% sure what your web page does, but assuming you have a PersonAssignment Id and you're retrieving a PersonAssignment object from that, and then the Person object itself, the following might make it easier:

In the PersonAssignment class, add a property referencing the Person object rather than just a person_id. From your example:

PersonAssignment Class
id
person_id
Person person
Address assignedAddress
Position assignedPosition

In the GetPersonAssignment method (which I assume takes a parameter), do some work to populate the Person object. You'll need to add to the Insert and Update methods to take this into account as well.

Answer 4

Depending on your rules it appears each person can only have one address, so if someone moves you lose his last address as there is no person_id in the address table.

But, that is nitpicking.

Using a DAO, as mentioned above, is an excellent idea. Keep the logic separate.

I would start with writing the DAO, make certain it is doing everything it is supposed to do, then work on the next layer up, that way you can make any changes to the database that is needed.

If you are new to C# you may want to look at the various tools that .NET 3.5 provides as there were many changes to make database access simpler, to abstract out the actual database.

One advantage of this is that some of your data sources may come from an XML file and your DAO will work fine regardless of the actual source of the data source.

Answer 5

It sounds like you're working within a framework that was designed by someone else where you have services classes, repositories, and a DAL, and now that you have all this stuff you're looking at the big pile of code and asking "isn't there an easier way". The short answer is yes, there is always an easier way. There are as many different ways of doing data access as there are developers. The model you're using is fairly complex and sounds like it follows the principles of Domain Driven Design. DDD is a great methodology and it provides excellent separation of concerns and high testability. But it also requires a lot of plumbing code and it's not well understood by most .Net programmers so getting help can be tough. I do think it's the best way to build enterprise applications, but it's not the best model for you to follow if you're new to OOP.

If you're doing a small project you might want to consider bypassing the BLL altogether, no services classes, no repositories, just have a Common Lib/project that contains your entity classes and build a DLL that contains data access methods that directly populate and save your entities.

An even simpler approach is to do away with the entity classes and just have your DLL return ADO.Net DataTables that contain your entity data. This approach looses the strong typing of an entity class but it is much easier to implement.

Another approach is to use Entity Framework. EF will do all of this for you and it will generate strongly typed entity classes. It does take a little while to get used to EF but once you understand how to work with it, it can drastically reduce the time it takes you to write persistence code. For some good tutorials on EF, check out Rob Bagby's blog