|
»
Where to put the logic?
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
 |
Where to put the logic?
by dan06
::
Rate this Message:
Hi,
I'm in the process of learning stripes and to that end I'm putting together a simple module, but I'm stuck on where to put my "business logic." If anyone can point me in the right direction I'd appreciate it. Currently I have: 1. A controller that receives form information 2. A model that only reflects a database table 3. A DAO that using jpa/hibernate performs a simple select query based on the form information received by the controller. Thanks. -Dan ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by Grzegorz Krugły
::
Rate this Message:
I have controllers (Stripes Actions) that receive/send information
from/to forms and a JPA model and I put my logic into EJBs. So, I have multiple EJBs for different purposes (cart management, user management, etc.) and a front-facade EJB that delegates to these EJBs. I use facade's methods in my Action controllers. This might be an overkill for simpler applications, but for more complex is quite good. Best regards, Grzegorz Dan King pisze: > Hi, > > I'm in the process of learning stripes and to that end I'm putting together a simple module, but I'm stuck on where to put my "business logic." If anyone can point me in the right direction I'd appreciate it. > > Currently I have: > 1. A controller that receives form information > 2. A model that only reflects a database table > 3. A DAO that using jpa/hibernate performs a simple select query based on the form information received by the controller. > > Thanks. > > -Dan > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > https://lists.sourceforge.net/lists/listinfo/stripes-users > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by Clifford, Thomas
::
Rate this Message:
For writing larger apps that you need to keep the buslogic separate, I
would: 1. Keep the action beans (controller?) for interacting with the user interface (presentation layer). 2. Use a service layer that takes requests from action beans, and returns what the UI needs, often dao/model objects or recordsets in the form of dao/model arraylists. You can encapsulate your business rules in this service layer, requiring neither presentation (UI) or data (dao/model) layer to know about each other. 3. Use service layer to interact with the data (dao/model) layer, keeping the UI layer From having to know about the presentation layer. I can mock up an example if you'd like.... Tom C. -----Original Message----- From: Dan King [mailto:dan.king106@...] Sent: Monday, November 09, 2009 2:05 PM To: Stripes Users Subject: [Stripes-users] Where to put the logic? Hi, I'm in the process of learning stripes and to that end I'm putting together a simple module, but I'm stuck on where to put my "business logic." If anyone can point me in the right direction I'd appreciate it. Currently I have: 1. A controller that receives form information 2. A model that only reflects a database table 3. A DAO that using jpa/hibernate performs a simple select query based on the form information received by the controller. Thanks. -Dan ------------------------------------------------------------------------ ------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by dan06
::
Rate this Message:
Tom,
I'd appreciate it if you could mock up an example; it would significantly help me better understand the various interactions between the objects and the overall concept. Best, Dan ----- Original Message ---- From: "Clifford, Thomas" <cliffo60@...> To: Stripes Users List <stripes-users@...> Sent: Mon, November 9, 2009 2:18:07 PM Subject: Re: [Stripes-users] Where to put the logic? For writing larger apps that you need to keep the buslogic separate, I would: 1. Keep the action beans (controller?) for interacting with the user interface (presentation layer). 2. Use a service layer that takes requests from action beans, and returns what the UI needs, often dao/model objects or recordsets in the form of dao/model arraylists. You can encapsulate your business rules in this service layer, requiring neither presentation (UI) or data (dao/model) layer to know about each other. 3. Use service layer to interact with the data (dao/model) layer, keeping the UI layer From having to know about the presentation layer. I can mock up an example if you'd like.... Tom C. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by Clifford, Thomas
::
Rate this Message:
I can do that. I cannot remember seeing anything on the list that says
postings with attachments are allowed; does anyone know if I can attach a jar when I'm done ? -----Original Message----- From: Dan King [mailto:dan.king106@...] Sent: Monday, November 09, 2009 2:57 PM To: Stripes Users List Subject: Re: [Stripes-users] Where to put the logic? Tom, I'd appreciate it if you could mock up an example; it would significantly help me better understand the various interactions between the objects and the overall concept. Best, Dan ----- Original Message ---- From: "Clifford, Thomas" <cliffo60@...> To: Stripes Users List <stripes-users@...> Sent: Mon, November 9, 2009 2:18:07 PM Subject: Re: [Stripes-users] Where to put the logic? For writing larger apps that you need to keep the buslogic separate, I would: 1. Keep the action beans (controller?) for interacting with the user interface (presentation layer). 2. Use a service layer that takes requests from action beans, and returns what the UI needs, often dao/model objects or recordsets in the form of dao/model arraylists. You can encapsulate your business rules in this service layer, requiring neither presentation (UI) or data (dao/model) layer to know about each other. 3. Use service layer to interact with the data (dao/model) layer, keeping the UI layer From having to know about the presentation layer. I can mock up an example if you'd like.... Tom C. ------------------------------------------------------------------------ ------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by KR-11
::
Rate this Message:
Why not just use pasting some example code directly info:
http://pastebin.com/ "Clifford, Thomas" <cliffo60@...> wrote in message news:95B8F3E141EC924FA22C3C761A39193A01A6122F@...... >I can do that. I cannot remember seeing anything on the list that says > postings with attachments are allowed; does anyone know if I can attach > a jar when I'm done ? > > -----Original Message----- > From: Dan King > [mailto:dan.king106@...] > Sent: Monday, November 09, 2009 2:57 PM > To: Stripes Users List > Subject: Re: [Stripes-users] Where to put the logic? > > Tom, > > I'd appreciate it if you could mock up an example; it would > significantly help me better understand the various interactions between > the objects and the overall concept. > > Best, > Dan > > > > ----- Original Message ---- > From: "Clifford, Thomas" > <cliffo60@...> > To: Stripes Users List > <stripes-users@...> > Sent: Mon, November 9, 2009 2:18:07 PM > Subject: Re: [Stripes-users] Where to put the logic? > > For writing larger apps that you need to keep the buslogic separate, I > would: > > 1. Keep the action beans (controller?) for interacting with the user > interface (presentation layer). > 2. Use a service layer that takes requests from action beans, and > returns what the UI > needs, often dao/model objects or recordsets in the form of dao/model > arraylists. > You can encapsulate your business rules in this service layer, > requiring neither > presentation (UI) or data (dao/model) layer to know about each other. > 3. Use service layer to interact with the data (dao/model) layer, > keeping the UI layer > From having to know about the presentation layer. > > I can mock up an example if you'd like.... > > Tom C. > > > > > ------------------------------------------------------------------------ > ------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > https://lists.sourceforge.net/lists/listinfo/stripes-users > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by Stephen Nelson-7
::
Rate this Message:
On 9 Nov 2009, at 19:04, Dan King wrote:
> Hi, > > I'm in the process of learning stripes and to that end I'm putting > together a simple module, but I'm stuck on where to put my "business > logic." If anyone can point me in the right direction I'd appreciate > it. > > Currently I have: > 1. A controller that receives form information > 2. A model that only reflects a database table > 3. A DAO that using jpa/hibernate performs a simple select query > based on the form information received by the controller. > > Thanks. > > -Dan > > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Stripes-users mailing list > Stripes-users@... > https://lists.sourceforge.net/lists/listinfo/stripes-users Hi Dan I always try to keep as much domain/business logic in the domain objects themselves. Otherwise you've [probably] gone through the pain of O/R mapping for no tangible benefit. I generally use a service layer for co-ordinating things e.g. calling a service; parsing a result; storing a value in the data layer. It is then very easy to wrap a transactional around it - and even easier if you're using Spring. This kind of architecture is flexible without being overly so and is clearly defined so you know where to go when bug fixing or adding functionality. Regards, -- Stephen ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by KR-11
::
Rate this Message:
That's what I do as well. To me it seems that not using the model layer for
logic is a legacy necessity from the time there was no JPA and EJB 3. Question: Can we call this DDD, Domain Driven Design ? (Eric Evans) "Stephen Nelson" <stephen@...> wrote in message news:A17E926A-8456-45A2-A7B8-40BB0AECC221@...... > On 9 Nov 2009, at 19:04, Dan King wrote: > > > Hi Dan > > I always try to keep as much domain/business logic in the domain > objects themselves. Otherwise you've [probably] gone through the pain > of O/R mapping for no tangible benefit. I generally use a service > layer for co-ordinating things e.g. calling a service; parsing a > result; storing a value in the data layer. It is then very easy to > wrap a transactional around it - and even easier if you're using > Spring. This kind of architecture is flexible without being overly so > and is clearly defined so you know where to go when bug fixing or > adding functionality. > > Regards, > -- > Stephen > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by dan06
::
Rate this Message:
Hi Stephen, do you keep both the domain data and logic in the same domain object - i.e. the ORM object maps to a table and has domain logic? Or do you have one domain "data"/ORM object and another domain logic object? Best, Dan |
|
|
Re: Where to put the logic?
by KR-11
::
Rate this Message:
Hi Stephen,
I do something similar as Dan and I keep the domain data and logic together in the model objects. My impression is that keeping data and logic apart is often just a legacy architecture that was introduced in the time before EJB3 and JPA (but often still used with EJB3 and JPA). Before EJB3 the persistency layer was so separate and limited that it was a technical requirement to do it this way. But that's no longer the case as JPA comes very close to making your plain old objects (POJO's) persistent. So this way of working is now much closer to regular object oriented design. This kind of design of course integrates the model and database design. The database schema becomes part of you're projects development. That means that this kind of architecture does not seem to work well with (static of external) legacy database models that are not part of you're project. Regards, Karen "dan06" <dan.king106@...> wrote in message news:26312551.post@...... > > > Stephen Nelson-7 wrote: >> >> Hi Dan >> >> I always try to keep as much domain/business logic in the domain >> objects themselves. Otherwise you've [probably] gone through the pain >> of O/R mapping for no tangible benefit. I generally use a service >> layer for co-ordinating things e.g. calling a service; parsing a >> result; storing a value in the data layer. It is then very easy to >> wrap a transactional around it - and even easier if you're using >> Spring. This kind of architecture is flexible without being overly so >> and is clearly defined so you know where to go when bug fixing or >> adding functionality. >> >> Regards, >> -- >> Stephen >> > > Hi Stephen, > > do you keep both the domain data and logic in the same domain object - > i.e. > the ORM object maps to a table and has domain logic? Or do you have one > domain "data"/ORM object and another domain logic object? > > Best, > Dan > -- > View this message in context: > http://old.nabble.com/Where-to-put-the-logic--tp26271911p26312551.html > Sent from the stripes-users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by Stephen Nelson-7
::
Rate this Message:
On 12 Nov 2009, at 02:51, dan06 wrote: > > Hi Stephen, > > do you keep both the domain data and logic in the same domain object > - i.e. > the ORM object maps to a table and has domain logic? Or do you have > one > domain "data"/ORM object and another domain logic object? > > Best, > Dan > -- > Hi Dan, Yes - same domain object. Otherwise you end up duplicating everything and mapping from one inheritance hierarchy to another. The ORM tool is taking care of all the difficult mapping from object to database so your domain object can truly become an intelligent business object and not an anaemic domain model [1] [2] Hope this helps. Cheers, -- Stephen [1] http://en.wikipedia.org/wiki/Anemic_Domain_Model [2] http://martinfowler.com/bliki/AnemicDomainModel.html ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
|
|
Re: Where to put the logic?
by Stephen Nelson-7
::
Rate this Message:
On 12 Nov 2009, at 10:33, KR wrote: > Hi Stephen, > > I do something similar as Dan and I keep the domain data and logic > together > in the model objects. > > My impression is that keeping data and logic apart is often just a > legacy > architecture that was introduced in the time before EJB3 and JPA > (but often > still used with EJB3 and JPA). Before EJB3 the persistency layer was > so > separate and limited that it was a technical requirement to do it > this way. > But that's no longer the case as JPA comes very close to making your > plain > old objects (POJO's) persistent. So this way of working is now much > closer > to regular object oriented design. > > This kind of design of course integrates the model and database > design. The > database schema becomes part of you're projects development. That > means that > this kind of architecture does not seem to work well with (static of > external) legacy database models that are not part of you're project. > > Regards, > Karen > Hi Karen, I think we agree here - I'm advocating keeping the domain data and logic in the same class for the reasons you mentioned. I've only done a small amount of EJB3 in my past and I can attest to the lack of features it provided. Such that, entity beans were generally ignored in place of session beans and basically value objects containing data. So the present day technologies such as JPA are so much better - it's actually fun now! Cheers, -- Stephen ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-users mailing list Stripes-users@... https://lists.sourceforge.net/lists/listinfo/stripes-users |
| Free embeddable forum powered by Nabble | Forum Help |
