Need help on 3-Tier Architecture Concept

Sorry if this post should'nt belong here. I'm new to programming and I need advise as to whether my concept on a simple 3-tier architecture design make sense.

I have a project (presentation layer) containing just the window forms. A project (business logic layer) that contains the objects classes. And a project (data access layer) that contains the DAOs.

The presentation layer project has a reference to the business logic project. So in this way, I created a object based on values keyed into the presentation layer forms. In the business logic projects, in my object class, I have a void MyObj.AddObject() which calls the Data access project's MyObjDAO.InsertObject(MyObj obj) that performs the database insertion.

I went ahead with this concept and realise my folly. 2 things happen here: firstly, there is a circular dependency which is not allowed (Business reference Data Access and Data Access reference Business). However if you have added a reference to the business logic dll file instead, you face the error whereby your presentation layer make more than 1 reference to the same assembly.

What i want to achieve is to pass the object created from the presentation and insert into Database by passing the created object around so that a 3 -tier design and decoupling are followed. Can anyone be kind to share some light on a design approach that can accomplish the above and also to achieve a good 3 tier design. Sorry if this sounds newbie.

I am having these impressions:

1. Not have the DAO in a separate project. This avoids having to add a reference to the Business dll. But does that considered a 3-tier approach too?

2. Design the signatures of DAO.InsertObject() to accept parameters (string, boolean, int) and perform the necessary insertion within the method.

 

Thanks,
ZR 

decouple them by making use of interfaces. the business objects should reference the data access layer only via interfaces. for example, instead of using MyObjDAO your business objects should make use of IObjDAO or something to that effect. your actual data access layer will be an implementation of the interface(s). this way you avoid circular reference. inversion of control (IoC) or dependency injection techniques can be very helpful here.

Thanks Cruizer, will look into using interface approach.

There is no strict requirement to limit oneself to just three projects for a three-tier architecture. You can have a Core or DataSet project that represent your data entities or DTOs (Data Transfer Object). They are pure data structures and have no business/domain code. This is the raw level that the data access layer understands; both the data layer and business layer reference this assembly.

Upon passing up to the business/domain layer, it is up to you to reuse the same DTO (wrapping in a more complex business object) or build a new business object based on the DTO data. Designs that use DataSets usually work on the same DataSet/DataTable objects without further transformation. More complex solutions may merge/transform between a public version and an internal version of the DataSet depending on any security requirements that restrict certain data to only live in the internal layers.

i think u cld use the concepts from http://www.lhotka.net/ where u can pick up his book from the NLB Expert C#2005 Business Objects, has a pretty easy to follow framework. Alternatively can also follow our fellow forumer's firedancer layered app framework.

Thanks, icelava and tuono!

Yup, I certainly gain more from your help and working through these few months with exposure to strongly-typed datasets (thanks to icelava).

The Expert C#2005 Biz Objects looks interesting and might just contain what I was looking for! Thanks for that reference. I will read more in depth into these technologies.

 

Cheers!