Question about N-Tier Structure 1

[NipsMG]

Hi everyone.

I've got a program at the moment that I'm writing that generates different types of reports. The processs that generates the data requires a large amount of analysis and takes a decent amount of overhead. What I'm planning on doing is completely separating out the data generation classes into a seperate tier, having each one implement a ICustomReport interface I wrote, and having the interface (whether it be web, GUI, whatever) instantiate a ReportGenerator class, fire a GenerateReport(ReportType) function asynchronously, and get back an object created from that interface. This should make it easy to add new reports later without having to change the user interface much, if at all.

However, in the user interface, I have to give the user parameters to select in order to generate the report. These parameters include customer part numbers that have to be pulled from a database.

My question is, is it a mortal sin design wise to add the code for pulling the customer part numbers from the database into the Interface tier? If so, does anyone have any pointers on how to handle it correctly?

Also, if anyone has recommendations for sites or books that do a good job of covering N-Tier development, I'd appreciate that also.

Please only answer if you have a decent amount of experience with this type of design.

Thanks in advance.

--NipsMG

 

[chiph]

Your presentation layer can call another layer to do the work of returning you a list of part numbers, but it shouldn't do it itself.

A good book is Martin Fowler's Enterprise Application Architecture. Expensive, but worth every cent, as he goes into discussions of this sort of thing.

Chip H.


____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[ThatRickGuy]

In my show we have a nice standard set up for abstraction.
For the most part it is:

GUI - Business Layer - Data Layer - Database

We have an application that sounds similar to what you're writeing. Our primary form displays a tree view with all the reports/letters/invoices, and a panel on the right. The panel gets filled according to your selection on the left. The objects filling the panel talk to the busines layer which returns information from the data layer to populate options and parameters.

When the user hit's the run button, a base report object(handles threading/printering/CR/Word etc) is created, it is set to the type of report object we need to run, gathers the parameters from the gui, and starts the process.

The nice part is that since everything is abstract, we can move elements from one app to another, or even to a web app with out having to change the code (has save uber time already). And since everything gets inherited from a hand full of base classes, we can write some really abstract code and just toss in what ever object is needed.

-Rick

----------------------

http://www.ringdev.com

 

[NipsMG]

I'm trying to design in this way more frequently. However, I've found it extremely cumbersome in many cases to make a separate data layer in front of the databsae. Too often, there's come complex data operations that jsut don't lend themselves to a black box, one size fits all, data layer.

I think I need to read more on the subject however.

 

[ThatRickGuy]

I disagree NipsMG. At first I felt similar though, but after 4 months of working with just such a system, we have a fairly refined data layer set up. The entire thing is based of inheritance of a single class (Base_DO) which is inherited by 2 classes (BaseSQL_DO, BaseOLE_DO) that specify object types (SQLServer objects vs OLE) Those objects are then inherited by objects named after the database they reflect that specify database specific info. Those objects are then inherited by a data object that reflects a specific table, query, or view. Each of those objects are just a few short subs that specify the SQL/Stored Procedure, property names and what not.

At first, we ran into the same problem, how to handle complexe queries w/ abstract data objects? The answer was simple. Make a new abstract data object w/ the SQL/SP we need.

It now takes about 10 minutes to put together all of the code for a new data object, no mater how complexe. And we have a lot of base functionality built in. save/update/delete being the biggies, and lots of data specific stuff too.

-Rick

----------------------

http://www.ringdev.com

 

[NipsMG]

That's the kind of thing I'd love to do. It makes so much sense to do things that way, but it would be much easier for me to visualize if I had some form of example.

The issue is, I've got a company of 200 people here, and at the moment, a 2 person IT department.

My many hats include IT Manager, Network Admin, Database Admin, Lead software developer. I've got a systems guy that deals with most end-user issues.

Large projects like that take a lot of planning. Ideal situations for me happen when I can get ahold of some kind of base-level plan or example that I can build off of. With the million and one things going on in a day, it's hard to get something like that off the ground. However, the value of it once it's in place will be immesurable, I'm sure.

--NipsMG

 

[ThatRickGuy]

Our solution is still maturing, but I think it's becoming more and more solid. Unfortunatly there is one major flaw. It's a flaw that drives me nuts, but I'm not alloud to correct.

The original developer won't allow us to have a single layer of data access. There is a data access layer, and a business data acces layer. This just drives me nuts. All the damn 2nd layer does is objescure to property names so we have to call them with late binding. If it weren't for that, I'd be tempted to start posting this solution as an abstract template.

-Rick

----------------------

http://www.ringdev.com

 

[chiph]

A typical reason for a business-data layer is to manage DB transactions. Since they're coordinated at the DB Connection level, you can't have them done down in the CRUD methods. They need to be at a higher level in order to have transactions that encompass both an Invoice and InvoiceDetail update operation.

Chip H.


____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[ThatRickGuy]

I understand that the transactions need to be invoked from above the data layer, but their actual function is of the data access layer. By tracking the transactions in the database object, we can control the transactions based off of the database instead of the data object. This portion of the structure hasn't been implimented yet, but the plan is in place.

The PITA of this Data_BO/Data_DO is that the DO (Data object) takes care of calling stored procedures or SQL, building dynamic SQL, etc. The BO contains SetData and GetData. Which both require the property name to be passed in, thus removing all intelisence. In some places, it is also used to handle business logic related to the data. Which is a valid use. But could also be handled by a business object that is not directly tied to the data object.

-Rick

----------------------

http://www.ringdev.com