• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Where to put the business logic?

 
Vikas Sood
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear Friends,
I am doing the FBN assignments for the last 2 months,and have done al ot of research on the design specs of FBN assignment,but am still having some doubts.One of those is the positioning of business logic that is mainly the bookSeats method,should we have generic server or a generic client?
By the specs given by Sun it sems that we need a generic server as they have asked us to have a DataClent having all the public implementations of Data.But makes our clent specific to FBN and as clients might be widely distributed changing or enhancing them is going to be very difficult,that is ,if in future the FBN application is to be upgraded for wider implmentation.While if we have the 3 tier approach that is having a bussiness layer than i think only enhancement when the FBN app is to upgraded will occure at the Server.
Kindly comment.Thankx in advance.
Vikas Sood
 
Thomas Fly
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vikas,
In the U.S., there is often a kind of rude reply to the kind of question, "Where to put the business logic?"
There's really not a heck of a lot of business logic involved in this application; on the other hand, classes should have tightly focused responsibilities, which tends to lead to a classic Model-View-Controller partitioning (the Controller is essentially responsible for the "business logic").
It strikes me that there's an awful lot of hype associated with "Object Oriented Programming." I'd have partitioned the responsibilities required of this application in much the same way as I've done it in Java, if I'd been writing the program 12 years ago in C.
The overreaching principles are the same; only the details of the approach have changed.
 
Pete Lyons
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As Thomas said, this assignment has very little business logic. However, the little that is there should go into a "Model" class. For example, I created a class called Flight to encapsulate the flight data and behavior, and it had the responsibility of throwing a NotEnoughSeatsException if you tried to book more seats than it had available. A good guideline would be to ask yourself if you would have to re-write or move any of the "business" code to create an HTML based web application, for example. If you would be able to re-use your business objects, than your design is probably pretty cleanly separated. If you have code inside your UI classes that does non-UI stuff, that's bad.
 
Vikas Sood
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends,
I got ur point,that is if i am getting u correctly is to have what ever buisness logic there is on the server side so as to be able to have a scalable system.
And also i agree with Pete that Ui shold have as little knowledge of the processing as posible.It should be more generic.
But what about the Sun's spec which has asked us to provide all the public methods of the Data in DataClient class,if we dont do that,will it be ok to just give proper justification for it,and expect Sun to understand ur point,which is much more closer to object oriented programming.
Kindly Comment.
VikasSood
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vikas, imagine this.
You have an interface that has all the public methods of the Data class, you have two implementing classes of this interface that is for local and remote and they implement all the public Data methods.
Now here's the fun part, we want to add a Facade class/pattern. What this does is hide the more complicated underlying classes with a class that can be used with ease.
The Facade has a method called bookFlights, in it it calls the local or remote classes (Actually the interface) to do all the work. Now your GUIController only has to have a Facade instance and when you hit the book button, bam (Emeril here) you call the bookFlights method.
Hope that helps.
There is nothing better than OOP when you see it clearly.
Mark
 
Thomas Fly
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oops, I stand corrected (that's what happens when you try to give advice at 3AM).
Pete is right; however, the "business logic" should not be in a low-level class like FBN's Data class, which should largely be kept ignorant of "higher-level" issues.
 
Vikas Sood
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends,
From the discussion this far what i get is that the Data class and related classes should be generic and should not have any knowledge of the high level processing that is FBN specific info.
Mark from what u and pete has sugessted it seems that i need to have bookSeats in my DataClient or Flight or any other name that can be,which acts as a facade for Data or RemoteData for getting the work done.When i use it like a facade then i think i am not suppose to include all the public methods of Data in my clent side facade.Am i right? if yes than it means I go against the specs of the assignment which require us to have the same public interface as Data.Or just proper justification wll do?
Or else i have the bookSeats in the Client side but apart from that i include all the public methods of Data also.
I am at the moment planning to have the bookSeats at the client side along with all the public methods of Data but i am not going call them directly.
Kindly Comment!
VikasSood
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Facade wraps around your DataAccess class that implements the interface which has the public methods of Data, so you are providing the Data methods to the client like the specs say, you just have one more level of indirection to waht the GUIController actually calls the Facade method, which calls a Method in DataAccess class which passes it to Data.
The Facade is still in the db package, but used by the client.
Mark
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my opinion, placing the facade class to the suncertify.db package breaks the rules. My intuition says that the db package should only contain classes implementing the database, not the classes of the business application using that database.
In other words, I'd put the facade in suncertify.client or something like that.
 
fadi mujahid
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my case, I added a layer over the Data class that holds the "business logic". I used it to control access to the Data class (locking, unlocking) and that's mainly the business logic of the application.
OO is very interresting when u see the full picture
My 2 cents
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lasse, but is it exactly the client which is the GUI/Model and Controller.
But you are also right in that it isn't an actual data class.
It's almost like it is in the middle tier.
so what do think would be a good package name for it.
suncertify.middletier
or
suncertify.business
or
suncertify.businesslogic
I like the second one.
Mark
 
Thomas Fly
Ranch Hand
Posts: 164
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've got a suncertify.db package (which has a suncertify.db.exceptions package underneath it) and a suncertify.fbn package (also with some stuff underneath it).
suncertify.fbn.DataAccess contains my "business logic" (as I hope the name implies ).
This is really a pretty simple project; there's no need to proliferate classes & packages pointlessly... to the contrary, there are good reasons to minimize the number of each, while keeping each class well-focused, and good cohesion (but loose coupling) between the classes within each package.
Packages are ultimately just another name for "directory." If you know how to organize the files within your computer using directories, then you understand how to organize your code into classes & packages.
 
Vikas Sood
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends,
I have been going through the discussion this far.I think i am going to add a class by the name of FBNFacade over DataClient for defining methods which will be accessible by client GUI(DataClient will be defining all the public methods of Data).
And planning to keep it in my client package only,instead of haiving another package by the name of buisness or fbn.This way i am keeping it simple as this assignment is not equivalent to a real life commercial project and as such there isnt much buisness logic involved.
Another question i would like to ask is are we not making it too complex by having an approach like this :
GUI >> FBNFacade >>DataClient >> Data/RemoteData
I know above sounds more OO design but is it really needed to be this way,or cant we keep it simple by some other way.
VikasSood
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Spritzler:
so what do think would be a good package name for it.
suncertify.middletier
or
suncertify.business
or
suncertify.businesslogic
I like the second one.

Actually, I like the one Thomas uses: suncerfity.fbn. I think I'll reorganize my packages under suncertify.fbn.gui and suncertify.fbn.domain or something like that...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic