Design Issue: Multiple definitions of db in separate prjcts. Aggregating prjcts in 1 sln. Help eliminating redundancy

Hi. ...As you probably noticed by my thread title, I am having a design issue and would like it if you could help.

...What I am making is a meal planner (in C#.NET) The relevant modules that cause the problem are my "RecipeManager" and my "IngredientManager." A little background on why this arose: I encapsulate my db connectivity objects and my dataset into 2 classes, clsDatabase and clsQueryResults(It's how we learned in college.) The flow of logic from the UI to the db goes something like this UI->Application->clsDatabase->ADO.NET->...->database
...I didn't wanna take the time to fill in the "..." ;) ...you get the idea. But now, I have 2 projects running in the same solution that use this logic, and each of them have clsDatabase and clsQueryResults in them. I want to pull clsDatabase & clsQueryResults out of these libraries and encapsulate them in their own specific layer. The problem is that for security purposes, all of the db methods were given access-level 'internal.' If I pull them out into their own library, I can no longer access them from RecipeManager or IngredientManager. But, if I make them public, they become exposed to everything, and that I do not want. I want to fit the requirements that the database is still exposed to the individual libraries 'RecipeManager' and 'IngredientManager' from a singular location while still maintaining the integrity of the original logical flow. Does anyone know of an elegant solution to this problem

(To help clarify)
My logical flow currenty goes something like this:
UI->Application->|->RecipeManager -->|clsRecipe -->| -- Database
| |
|->IngredientManager -->|clsIngredient -->| -- Database

I want it to look something like this:

UI->Application->|->RecipeManager -->|clsRecipe -->|
| | |-->Database
|--IngredientManager -->|clsIngredient -->|

Any suggestions would be appreciated, even ones that completely shred my logical flow if that is required. I just want to solve the problem.

Answer this question

Design Issue: Multiple definitions of db in separate prjcts. Aggregating prjcts in 1 sln. Help eliminating redundancy

dotnetsekar
Could you please elaborate on the statement

"Also, have in mind that if you add Typed DataSets to your project in a different component will help you as a transpor layer, so, you can use the same objects for interacting with your UI, business logic, and data acccess layer."

(Can't look at the patterns .pdf doc right now. It wouldn't open after I downloaded it for some reason.)
stallion_alpa

Hi Alan,

I think you are trying to build a n-layered application.

Initially, You need to have a data access layer. In this layer, you have to create a DLL ( component ) that give you access to the Database. I do not see anything wrong having these clases as a separated component, and I don see anything wrong about security. Putting a class as internal does not give you more security than you will have using an external component. Besides, I think your classes for data access layer, must contain static methods, cause you dont need to maintain any state for that class, just go and pick up or sent the information need it. Also, have in mind that if you add Typed DataSets to your project in a diferent component will help you as a transpor layer, so, you can use the same objects for interacting with your UI, business logic, and data acccess layer.

Take a look at this document at Microsoft Patterns web site, where they explain in very depth detail about n-layered applications and about all the things I've written.

Best Regards,
Chaman Zinga

Yes,

when you create a n-layer application ( which I think is something you are trying to do now ) you have to select a way to move information between layers ie between Data Access layer, bussines layer and UI. One option is to have Typed DataSets to move a query result for example, from the Access layer to the UI ( for databinding porpuses for example ). So, those componenst are usually placed in a DLL which you can call business componets. This components can be accessed by all the layers so, they all have the same transport for moving data from UI to DB ( as they are DataSets, they can also be used to transport data thourgh web services).

so we can say you will have 3 layers besides UI and DB:

1. DataAccess Layer: This layer allows you to interact with the database. It has all the information necesary for accesing the data sources.

2. Business Component Layer: Typed DataSets that contain the information for moving through the layer - including UI.

3. Business Logic Layer: All the bussines objects you have designed --> this part is tipically you UML diagram implementation.

All of this components are DLLS, so any aplication can add them and interact against the datasource without being worried about that. So, you can have a windows application and then a Web application, and your components will be always the same. Besides, if you change your data source, for example from Access to SqlServer, the only layer worried about that is the 1. DataAccess layer, the rest of them are not interested on that, because they interact with the DACL.

Hope this helps on your arch design :)

Best Regards
Greg Y

You should use a DLL for the dataaccess layer component, And use the TypedDataSet as you containers so you wont need something like a query results, because the typed DataSet will give you that, besides, the Database class should be present for encapsulate things like getting connections or adding methods the make things easier for querying, or updating, etc. One thing you have to have in mind, is not to use dynamic queries except when is strictly necesary. Best option is to use Store procedures

Regards
Wolfgang Geppert
so are you basically saying that my clsDatabase class needs to be in its own library and my clsQueryResults class needs to be in a separate one
Design Issue: Multiple definitions of db in separate prjcts. Aggregating prjcts in 1 sln. Help eliminating redundancy

Answer this question