Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26261 > unrolled thread

Java EE Architecture

Back to article view | Back to comp.lang.java.programmer

Contents

  Java EE Architecture art.marole@gmail.com - 2013-10-09 13:41 -0700
    Re: Java EE Architecture Lew <lewbloch@gmail.com> - 2013-10-09 14:45 -0700
      Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-09 22:00 -0400
    Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-09 22:18 -0400
      Re: Java EE Architecture art.marole@gmail.com - 2013-10-10 00:47 -0700
        Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-16 20:37 -0400
    Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-10 13:26 +0100
      Re: Java EE Architecture 1connu <1connu999@gmail.com> - 2013-10-16 10:45 +0200
        Re: Java EE Architecture Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-10-16 13:42 +0300
          Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-16 11:55 +0100
            Re: Java EE Architecture Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-10-16 14:18 +0300
            Re: Java EE Architecture Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-10-16 14:25 +0300
              Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-16 14:23 +0100
                Re: Java EE Architecture Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-10-16 17:10 +0300
                  Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-16 16:44 +0100
                    Re: Java EE Architecture "L." <carisio@gmail.com> - 2013-10-16 10:15 -0700
                      Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-16 19:01 +0100
                        Re: Java EE Architecture "L." <carisio@gmail.com> - 2013-10-16 12:17 -0700
                          Re: Java EE Architecture Martin Gregorie <martin@address-in-sig.invalid> - 2013-10-16 21:01 +0000
                            Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-16 20:40 -0400
                    Re: Java EE Architecture Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-10-17 00:00 +0300
                Re: Java EE Architecture Wayne <nospam@all.invalid> - 2013-10-16 23:08 -0400
                  Re: Java EE Architecture Donkey Hottie <donkey@fredriksson.dy.fi> - 2013-10-19 17:05 +0300
                    Re: Java EE Architecture Lew <lewbloch@gmail.com> - 2013-10-19 14:48 -0700
                      Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-20 09:00 +0100
                        Re: Java EE Architecture "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-10-20 19:40 +1100
                          Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-20 10:07 +0100
            Re: Java EE Architecture Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-16 20:14 -0400
              Re: Java EE Architecture lipska the kat <"lipskathekat at yahoo dot co dot uk"> - 2013-12-17 08:47 +0000
          Re: Java EE Architecture Jeff Higgins <jeff@invalid.invalid> - 2013-10-16 20:19 -0400
            Re: Java EE Architecture Jeff Higgins <jeff@invalid.invalid> - 2013-10-16 21:24 -0400
        Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-16 11:49 +0100
          Re: Java EE Architecture "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-10-16 22:24 +1100
            Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-16 13:39 +0100
              Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-16 20:39 -0400
                Re: Java EE Architecture "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-10-17 13:43 +1100
                Re: Java EE Architecture Jeff Higgins <jeff@invalid.invalid> - 2013-10-16 23:22 -0400
                  Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-17 08:53 +0100
                Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-17 08:57 +0100
                  Re: Java EE Architecture "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-10-17 19:31 +1100
                    Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-17 09:56 +0100
                      Re: Java EE Architecture "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-10-17 20:18 +1100
                        Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-17 10:56 +0100
                          Re: Java EE Architecture "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-10-17 21:39 +1100
                            Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-17 12:08 +0100
                    Class Person [was: Java EE Architecture] "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-10-18 08:19 +0100
                  Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-17 21:00 -0400
                    Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-17 21:02 -0400
                      Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-18 09:06 +0100
                    Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-18 09:04 +0100
                      Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-19 22:43 -0400
                        Re: Java EE Architecture lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-10-20 09:05 +0100
                          Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-20 09:24 -0400
        Re: Java EE Architecture Arne Vajhøj <arne@vajhoej.dk> - 2013-10-16 20:43 -0400

Page 1 of 3  [1] 2 3  Next page →

#26261 — Java EE Architecture

Hi all,

I would like to prepare typical Java EE solution (EJB, JSF, JPA) now, and I have quite stupid problem related with domain objects. I want to create Person class as persistence class, but I don't know in which module I shoud put this class: Business Layer (ejb module) or in Integration Layer (jar module).

Person class is more related with logic, so I should put it in ejb module, but in this case I will need to create dependency relation from Integration Layer to Business Layer as Integration Layer need to know what object should store in DB (ex. void store(Person object){};).
Put Person class in Integration Layer will remove this unwanted dependency, but I feel that Person class is more Business class then Integration class.

What do you think about it?

[toc] | [next] | [standalone]

#26262

art.m...@gmail.com wrote:
> I would like to prepare typical Java EE solution (EJB, JSF, JPA) now, and I have quite stupid problem related with domain objects. I want to create Person class as persistence class, but I don't know in which module I shoud put this class: Business Layer (ejb module) or in Integration Layer (jar module).

If you're using EJBs, your solution might not be typical.

You also left out "WAR" module. 

But honestly this question doesn't make sense to me. "EJB module"? "JAR module"? 
What do these terms even mean?

> Person class is more related with logic, so I should put it in ejb module, but in this case I will need to create dependency relation from Integration Layer to Business Layer as Integration Layer need to know what object should store in DB (ex. void store(Person object){};).
> 

'Person' is not, in JPA terms, an "object [to] store in [the] DB", but a typed entity that has a connection
to a data store for persistence. The data view in the data store will not be identical to the object 
view in the code that uses the 'Person' type.

From the upper layers' point of view, there is no notion of a database, only of the entity.

Typically the 'Person' will live in a "JAR" level, if I understand your use of the term correctly, 
which I probably don't, in that it is an entity without business logic.

> Put Person class in Integration Layer will remove this unwanted dependency, but I feel that Person class is more Business class then Integration class.

"Feel"?

> What do you think about it?

Use logic, not feelings.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#26266

On 10/9/2013 5:45 PM, Lew wrote:
> art.m...@gmail.com wrote:
>> I would like to prepare typical Java EE solution (EJB, JSF, JPA) now, and I have quite stupid problem related with domain objects. I want to create Person class as persistence class, but I don't know in which module I shoud put this class: Business Layer (ejb module) or in Integration Layer (jar module).
>
> If you're using EJBs, your solution might not be typical.
>
> You also left out "WAR" module.
>
> But honestly this question doesn't make sense to me. "EJB module"? "JAR module"?
> What do these terms even mean?

It sound slike Maven terms to me.

http://maven.apache.org/plugins/maven-ear-plugin/modules.html

Arne

[toc] | [prev] | [next] | [standalone]

#26267

On 10/9/2013 4:41 PM, art.marole@gmail.com wrote:
> I would like to prepare typical Java EE solution (EJB, JSF, JPA) now,
> and I have quite stupid problem related with domain objects. I want
> to create Person class as persistence class, but I don't know in
> which module I shoud put this class: Business Layer (ejb module) or
> in Integration Layer (jar module).
>
> Person class is more related with logic, so I should put it in ejb
> module, but in this case I will need to create dependency relation
> from Integration Layer to Business Layer as Integration Layer need to
> know what object should store in DB (ex. void store(Person
> object){};). Put Person class in Integration Layer will remove this
> unwanted dependency, but I feel that Person class is more Business
> class then Integration class.
>
> What do you think about it?

Your integration layer sounds very much like traditional
data access layer.

I would not put that class in business logic layer.

I would put it either in data access layer or in a separate
domain object layer.

Arne

[toc] | [prev] | [next] | [standalone]

#26276

W dniu czwartek, 10 października 2013 04:18:51 UTC+2 użytkownik Arne Vajhøj napisał:
> On 10/9/2013 4:41 PM, art.marole@gmail.com wrote:
> 
> > I would like to prepare typical Java EE solution (EJB, JSF, JPA) now,
> 
> > and I have quite stupid problem related with domain objects. I want
> 
> > to create Person class as persistence class, but I don't know in
> 
> > which module I shoud put this class: Business Layer (ejb module) or
> 
> > in Integration Layer (jar module).
> 
> >
> 
> > Person class is more related with logic, so I should put it in ejb
> 
> > module, but in this case I will need to create dependency relation
> 
> > from Integration Layer to Business Layer as Integration Layer need to
> 
> > know what object should store in DB (ex. void store(Person
> 
> > object){};). Put Person class in Integration Layer will remove this
> 
> > unwanted dependency, but I feel that Person class is more Business
> 
> > class then Integration class.
> 
> >
> 
> > What do you think about it?
> 
> 
> 
> Your integration layer sounds very much like traditional
> 
> data access layer.
> 
> 
I met with many names for this layer - yes, this is the data access layer.
> 
> I would not put that class in business logic layer.
> 
> 
> 
> I would put it either in data access layer or in a separate
> 
> domain object layer.
> 
> 
I agree with you. It should not be placed in business layer.
> 
> Arne

Law has wrote: If you're using EJBs, your solution might not be typical.
What is typical solution in Java EE? Do you mean Spring framework?

/Marcin

[toc] | [prev] | [next] | [standalone]

#26348

On 10/10/2013 3:47 AM, art.marole@gmail.com wrote:
> Law has wrote: If you're using EJBs, your solution might not be typical.
> What is typical solution in Java EE? Do you mean Spring framework?

Some use EJB's - some do not. I don't know if it 30%, 50% or 70% that
use EJB.

If database transactions are important for the application and/or
async business logic is required, then EJB's are quite nice.

In other contexts managed beans and POJO's will do just fine.

If you like Spring then use it if you don't then don't. I think
most Java EE apps use some Spring even though the need for
Spring has been heavily reduced with recent Java EE versions.

But you should not focus so much on what other use. Learn
about all Java EE technologies and relevant other frameworks
like Spring and then decide what fits your problem best.

Arne

[toc] | [prev] | [next] | [standalone]

#26281

On 09/10/13 21:41, art.marole@gmail.com wrote:
> Hi all,
>
> I would like to prepare typical Java EE solution (EJB, JSF, JPA) now, and I have quite stupid problem related with domain objects. I want to create Person class as persistence class, but I don't know in which module I shoud put this class: Business Layer (ejb module) or in Integration Layer (jar module).
>
> Person class is more related with logic, so I should put it in ejb module, but in this case I will need to create dependency relation from Integration Layer to Business Layer as Integration Layer need to know what object should store in DB (ex. void store(Person object){};).
> Put Person class in Integration Layer will remove this unwanted dependency, but I feel that Person class is more Business class then Integration class.
>
> What do you think about it?


A Person class ... A PERSON class., please, please, *please* don't have 
a Person class

For the sake of whatever omnipotent deity you pray to, do not have a 
Person class

*People* do not belong in a computer system.

Why?

Because it's a poor abstraction.

How are you going to model consciousness, sentience, the 'mind', the 
'soul'? let alone arms legs, eyes and teeth :-)

You *do not need* a Person class.

Let's put it another way

The very fact that you are having problems deciding where your Person 
belongs should alert you to the fact that it is a poor abstraction.

Try Account, or Record, or if you absolutely *must* User but not Person, 
you will end up regretting it.

lipska


-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26326

lipska the kat a écrit :
> On 09/10/13 21:41, art.marole@gmail.com wrote:
>> Hi all,
>>
>> I would like to prepare typical Java EE solution (EJB, JSF, JPA) now, 
>> and I have quite stupid problem related with domain objects. I want to 
>> create Person class as persistence class, but I don't know in which 
>> module I shoud put this class: Business Layer (ejb module) or in 
>> Integration Layer (jar module).
>>
>> Person class is more related with logic, so I should put it in ejb 
>> module, but in this case I will need to create dependency relation 
>> from Integration Layer to Business Layer as Integration Layer need to 
>> know what object should store in DB (ex. void store(Person object){};).
>> Put Person class in Integration Layer will remove this unwanted 
>> dependency, but I feel that Person class is more Business class then 
>> Integration class.
>>
>> What do you think about it?
> 
> 
> A Person class ... A PERSON class., please, please, *please* don't have 
> a Person class
> 
> For the sake of whatever omnipotent deity you pray to, do not have a 
> Person class
> 
> *People* do not belong in a computer system.
> 
> Why?
> 
> Because it's a poor abstraction.
> 
> How are you going to model consciousness, sentience, the 'mind', the 
> 'soul'? let alone arms legs, eyes and teeth :-)
> 
> You *do not need* a Person class.
> 
> Let's put it another way
> 
> The very fact that you are having problems deciding where your Person 
> belongs should alert you to the fact that it is a poor abstraction.
> 
> Try Account, or Record, or if you absolutely *must* User but not Person, 
> you will end up regretting it.
> 
> lipska
> 
> 
Why not ?
You can have an abstract class Person with minimum field (name, date birth) and sub class depending of role of theses persons (ex User (login/password) ) in your model.

[toc] | [prev] | [next] | [standalone]

#26327

16.10.2013 11:45, 1connu kirjoitti:
> lipska the kat a écrit :
>> On 09/10/13 21:41, art.marole@gmail.com wrote:
>>> Hi all,
>>>
>>> I would like to prepare typical Java EE solution (EJB, JSF, JPA) now,
>>> and I have quite stupid problem related with domain objects. I want
>>> to create Person class as persistence class, but I don't know in
>>> which module I shoud put this class: Business Layer (ejb module) or
>>> in Integration Layer (jar module).
>>>
>>> Person class is more related with logic, so I should put it in ejb
>>> module, but in this case I will need to create dependency relation
>>> from Integration Layer to Business Layer as Integration Layer need to
>>> know what object should store in DB (ex. void store(Person object){};).
>>> Put Person class in Integration Layer will remove this unwanted
>>> dependency, but I feel that Person class is more Business class then
>>> Integration class.
>>>
>>> What do you think about it?
>>
>>
>> A Person class ... A PERSON class., please, please, *please* don't
>> have a Person class
>>
>> For the sake of whatever omnipotent deity you pray to, do not have a
>> Person class
>>
>> *People* do not belong in a computer system.
>>
>> Why?
>>
>> Because it's a poor abstraction.
>>
>> How are you going to model consciousness, sentience, the 'mind', the
>> 'soul'? let alone arms legs, eyes and teeth :-)
>>
>> You *do not need* a Person class.
>>
>> Let's put it another way
>>
>> The very fact that you are having problems deciding where your Person
>> belongs should alert you to the fact that it is a poor abstraction.
>>
>> Try Account, or Record, or if you absolutely *must* User but not
>> Person, you will end up regretting it.
>>
>> lipska
>>
>>
> Why not ?
> You can have an abstract class Person with minimum field (name, date
> birth) and sub class depending of role of theses persons (ex User
> (login/password) ) in your model.

I see no problem with Person.

I have interface IPerson, and implementations Person and ExternalPerson.
I'm a lead programmer on an Identity Management solution.



-- 

Keep it short for pithy sake.

[toc] | [prev] | [next] | [standalone]

#26329

On 16/10/13 11:42, Donkey Hottie wrote:
> 16.10.2013 11:45, 1connu kirjoitti:
>> lipska the kat a écrit :
>>> On 09/10/13 21:41, art.marole@gmail.com wrote:
>>>> Hi all,
>>>>
>>>> I would like to prepare typical Java EE solution (EJB, JSF, JPA) now,
>>>> and I have quite stupid problem related with domain objects. I want
>>>> to create Person class as persistence class, but I don't know in
>>>> which module I shoud put this class: Business Layer (ejb module) or
>>>> in Integration Layer (jar module).
>>>>
>>>> Person class is more related with logic, so I should put it in ejb
>>>> module, but in this case I will need to create dependency relation
>>>> from Integration Layer to Business Layer as Integration Layer need to
>>>> know what object should store in DB (ex. void store(Person object){};).
>>>> Put Person class in Integration Layer will remove this unwanted
>>>> dependency, but I feel that Person class is more Business class then
>>>> Integration class.
>>>>
>>>> What do you think about it?
>>>
>>>
>>> A Person class ... A PERSON class., please, please, *please* don't
>>> have a Person class
>>>
>>> For the sake of whatever omnipotent deity you pray to, do not have a
>>> Person class
>>>
>>> *People* do not belong in a computer system.
>>>
>>> Why?
>>>
>>> Because it's a poor abstraction.
>>>
>>> How are you going to model consciousness, sentience, the 'mind', the
>>> 'soul'? let alone arms legs, eyes and teeth :-)
>>>
>>> You *do not need* a Person class.
>>>
>>> Let's put it another way
>>>
>>> The very fact that you are having problems deciding where your Person
>>> belongs should alert you to the fact that it is a poor abstraction.
>>>
>>> Try Account, or Record, or if you absolutely *must* User but not
>>> Person, you will end up regretting it.
>>>
>>> lipska
>>>
>>>
>> Why not ?
>> You can have an abstract class Person with minimum field (name, date
>> birth) and sub class depending of role of theses persons (ex User
>> (login/password) ) in your model.
>
> I see no problem with Person.
>
> I have interface IPerson, and implementations Person and ExternalPerson.
> I'm a lead programmer on an Identity Management solution.

You *cannot* be serious ... IPerson groan :-(

If you are developing an Identity Management system surely Identity 
might be a better abstraction ... just a thought.




-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26332

16.10.2013 13:55, lipska the kat kirjoitti:
> On 16/10/13 11:42, Donkey Hottie wrote:
>> 16.10.2013 11:45, 1connu kirjoitti:
>>> lipska the kat a écrit :
>>>> On 09/10/13 21:41, art.marole@gmail.com wrote:
>>>>> Hi all,
>>>>>
>>>>> I would like to prepare typical Java EE solution (EJB, JSF, JPA) now,
>>>>> and I have quite stupid problem related with domain objects. I want
>>>>> to create Person class as persistence class, but I don't know in
>>>>> which module I shoud put this class: Business Layer (ejb module) or
>>>>> in Integration Layer (jar module).
>>>>>
>>>>> Person class is more related with logic, so I should put it in ejb
>>>>> module, but in this case I will need to create dependency relation
>>>>> from Integration Layer to Business Layer as Integration Layer need to
>>>>> know what object should store in DB (ex. void store(Person
>>>>> object){};).
>>>>> Put Person class in Integration Layer will remove this unwanted
>>>>> dependency, but I feel that Person class is more Business class then
>>>>> Integration class.
>>>>>
>>>>> What do you think about it?
>>>>
>>>>
>>>> A Person class ... A PERSON class., please, please, *please* don't
>>>> have a Person class
>>>>
>>>> For the sake of whatever omnipotent deity you pray to, do not have a
>>>> Person class
>>>>
>>>> *People* do not belong in a computer system.
>>>>
>>>> Why?
>>>>
>>>> Because it's a poor abstraction.
>>>>
>>>> How are you going to model consciousness, sentience, the 'mind', the
>>>> 'soul'? let alone arms legs, eyes and teeth :-)
>>>>
>>>> You *do not need* a Person class.
>>>>
>>>> Let's put it another way
>>>>
>>>> The very fact that you are having problems deciding where your Person
>>>> belongs should alert you to the fact that it is a poor abstraction.
>>>>
>>>> Try Account, or Record, or if you absolutely *must* User but not
>>>> Person, you will end up regretting it.
>>>>
>>>> lipska
>>>>
>>>>
>>> Why not ?
>>> You can have an abstract class Person with minimum field (name, date
>>> birth) and sub class depending of role of theses persons (ex User
>>> (login/password) ) in your model.
>>
>> I see no problem with Person.
>>
>> I have interface IPerson, and implementations Person and ExternalPerson.
>> I'm a lead programmer on an Identity Management solution.
> 
> You *cannot* be serious ... IPerson groan :-(
> 
> If you are developing an Identity Management system surely Identity
> might be a better abstraction ... just a thought.
> 
> 
> 
> 

A Person may have more than one Identities. As well as more than one
UserAccounts.

-- 

Habit is habit, and not to be flung out of the window by any man, but coaxed
down-stairs a step at a time.
		-- Mark Twain, "Pudd'nhead Wilson's Calendar

[toc] | [prev] | [next] | [standalone]

#26334

16.10.2013 13:55, lipska the kat kirjoitti:
> On 16/10/13 11:42, Donkey Hottie wrote:
>> 16.10.2013 11:45, 1connu kirjoitti:
>>> lipska the kat a écrit :
>>>> On 09/10/13 21:41, art.marole@gmail.com wrote:
>>>>> Hi all,
>>>>>
>>>>> I would like to prepare typical Java EE solution (EJB, JSF, JPA) now,
>>>>> and I have quite stupid problem related with domain objects. I want
>>>>> to create Person class as persistence class, but I don't know in
>>>>> which module I shoud put this class: Business Layer (ejb module) or
>>>>> in Integration Layer (jar module).
>>>>>
>>>>> Person class is more related with logic, so I should put it in ejb
>>>>> module, but in this case I will need to create dependency relation
>>>>> from Integration Layer to Business Layer as Integration Layer need to
>>>>> know what object should store in DB (ex. void store(Person
>>>>> object){};).
>>>>> Put Person class in Integration Layer will remove this unwanted
>>>>> dependency, but I feel that Person class is more Business class then
>>>>> Integration class.
>>>>>
>>>>> What do you think about it?
>>>>
>>>>
>>>> A Person class ... A PERSON class., please, please, *please* don't
>>>> have a Person class
>>>>
>>>> For the sake of whatever omnipotent deity you pray to, do not have a
>>>> Person class
>>>>
>>>> *People* do not belong in a computer system.
>>>>
>>>> Why?
>>>>
>>>> Because it's a poor abstraction.
>>>>
>>>> How are you going to model consciousness, sentience, the 'mind', the
>>>> 'soul'? let alone arms legs, eyes and teeth :-)
>>>>
>>>> You *do not need* a Person class.
>>>>
>>>> Let's put it another way
>>>>
>>>> The very fact that you are having problems deciding where your Person
>>>> belongs should alert you to the fact that it is a poor abstraction.
>>>>
>>>> Try Account, or Record, or if you absolutely *must* User but not
>>>> Person, you will end up regretting it.
>>>>
>>>> lipska
>>>>
>>>>
>>> Why not ?
>>> You can have an abstract class Person with minimum field (name, date
>>> birth) and sub class depending of role of theses persons (ex User
>>> (login/password) ) in your model.
>>
>> I see no problem with Person.
>>
>> I have interface IPerson, and implementations Person and ExternalPerson.
>> I'm a lead programmer on an Identity Management solution.
> 
> You *cannot* be serious ... IPerson groan :-(
> 
> If you are developing an Identity Management system surely Identity
> might be a better abstraction ... just a thought.
> 
> 
> 
> 

We are managing the personnel of a company. A manager manager persons,
not identities.

A computer system is not supposed to model the liver or a soul of a
Person, but abstracts the properties that are relevant to the task.

A Person has a manager. An Identity does not.

-- 

Your society will be sought by people of taste and refinement.

[toc] | [prev] | [next] | [standalone]

#26336

On 16/10/13 12:25, Donkey Hottie wrote:
> 16.10.2013 13:55, lipska the kat kirjoitti:

<snip>

> We are managing the personnel of a company. A manager manager persons,
> not identities.
>
> A computer system is not supposed to model the liver or a soul of a
> Person, but abstracts the properties that are relevant to the task.

Well you said it.

> A Person has a manager. An Identity does not.

My local health service no longer calls people 'patients'. People who 
use the services are called unsurprisingly 'service users'

While I abhor the impersonal overtones of this particular bit management 
speak it makes perfect sense in terms of describing the entity concerned.

In the case you quote surely a manager manages Employees

or

An Employee *has a* Manager
A Manager manages one or more Employees
An Employee has one or more Roles
An Employee has an Identity (or many if you insist)
A Manager *is an* Employee
etc etc

No mention anywhere of the class *Person*

You state

'A Person may have more than one Identities' (sic)

I'd prefer 'An Employee can have one or more Roles/Identities'

A person with multiple identities doesn't really make sense does it?

How do you identify someone with multiple identities???



-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26337

16.10.2013 16:23, lipska the kat kirjoitti:
> On 16/10/13 12:25, Donkey Hottie wrote:
>> 16.10.2013 13:55, lipska the kat kirjoitti:
> 
> <snip>
> 
>> We are managing the personnel of a company. A manager manager persons,
>> not identities.
>>
>> A computer system is not supposed to model the liver or a soul of a
>> Person, but abstracts the properties that are relevant to the task.
> 
> Well you said it.
> 
>> A Person has a manager. An Identity does not.
> 
> My local health service no longer calls people 'patients'. People who
> use the services are called unsurprisingly 'service users'
> 
> While I abhor the impersonal overtones of this particular bit management
> speak it makes perfect sense in terms of describing the entity concerned.
> 
> In the case you quote surely a manager manages Employees
> 
> or
> 
> An Employee *has a* Manager
> A Manager manages one or more Employees
> An Employee has one or more Roles
> An Employee has an Identity (or many if you insist)
> A Manager *is an* Employee
> etc etc
> 
> No mention anywhere of the class *Person*
> 
> You state
> 
> 'A Person may have more than one Identities' (sic)
> 
> I'd prefer 'An Employee can have one or more Roles/Identities'
> 
> A person with multiple identities doesn't really make sense does it?
> 
> How do you identify someone with multiple identities???
> 
> 
> 

Indeed i our model a Person can have at most one identity. I remembered
wrong.


But then the Employee. And a Manager? (We do not have a Manager, but
Person has a property isManager).

A Person may be a Manager, AND is an Employee as well. Your model does
not work. He has an Identity, and multiple User Accounts. He is a
Person. Not an Employee. He may be an Employee, but the Owner of the
business is no such. A Person is a generalization of these, no need to
make the model too keen on details, too complicated. Or do we need a
Boss class too?


-- 

The lunatic, the lover, and the poet,
Are of imagination all compact...
		-- Wm. Shakespeare, "A Midsummer Night's Dream"

[toc] | [prev] | [next] | [standalone]

#26339

On 16/10/13 15:10, Donkey Hottie wrote:
> 16.10.2013 16:23, lipska the kat kirjoitti:
>> On 16/10/13 12:25, Donkey Hottie wrote:
>>> 16.10.2013 13:55, lipska the kat kirjoitti:
>>
>> <snip>
>>
>>> We are managing the personnel of a company. A manager manager persons,
>>> not identities.
>>>
>>> A computer system is not supposed to model the liver or a soul of a
>>> Person, but abstracts the properties that are relevant to the task.
>>
>> Well you said it.
>>
>>> A Person has a manager. An Identity does not.
>>
>> My local health service no longer calls people 'patients'. People who
>> use the services are called unsurprisingly 'service users'
>>
>> While I abhor the impersonal overtones of this particular bit management
>> speak it makes perfect sense in terms of describing the entity concerned.
>>
>> In the case you quote surely a manager manages Employees
>>
>> or
>>
>> An Employee *has a* Manager
>> A Manager manages one or more Employees
>> An Employee has one or more Roles
>> An Employee has an Identity (or many if you insist)
>> A Manager *is an* Employee
>> etc etc
>>
>> No mention anywhere of the class *Person*
>>
>> You state
>>
>> 'A Person may have more than one Identities' (sic)
>>
>> I'd prefer 'An Employee can have one or more Roles/Identities'
>>
>> A person with multiple identities doesn't really make sense does it?
>>
>> How do you identify someone with multiple identities???
>>
>>
>>
>
> Indeed i our model a Person can have at most one identity. I remembered
> wrong.
>
>
> But then the Employee. And a Manager? (We do not have a Manager, but
> Person has a property isManager).
>
> A Person may be a Manager, AND is an Employee as well. Your model does
> not work.

I think it does, read again, I said

An Employee *has a* Manager
A Manager *is an* Employee

> He has an Identity, and multiple User Accounts. He is a
> Person. Not an Employee. He may be an Employee, but the Owner of the
> business is no such. A Person is a generalization of these, no need to
> make the model too keen on details, too complicated. Or do we need a
> Boss class too?

Well in the first place Owner and Boss are two different concepts, in 
any case either the boss or the owner or both if they are different 
probably works for the company (even if he owns it, someone/thing has to 
pay him) in which case he/she is an Employee.

Don't forget, legally, here at least in the UK a (limited) company is a 
legal entity in it's own right, the company pays the wages, not the 
owner/boss/whoever ...

... and are you really saying that you need Person as a generalization 
because the Boss is not an Employee ... not much of a reason is it?

You say you are managing the personnel of a Company. What other types of 
personnel are there apart from Employees.

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26340

So I've read the signature: "Lipska the Kat©: Troll hunter".

I'm trying to understand how a "Troll hunter" can be a troll. How this thing can be modeled using OO principles?


Em quarta-feira, 16 de outubro de 2013 12h44min58s UTC-3, lipska the kat  escreveu:
> On 16/10/13 15:10, Donkey Hottie wrote:
> 
> > 16.10.2013 16:23, lipska the kat kirjoitti:
> 
> >> On 16/10/13 12:25, Donkey Hottie wrote:
> 
> >>> 16.10.2013 13:55, lipska the kat kirjoitti:
> 
> >>
> 
> >> <snip>
> 
> >>
> 
> >>> We are managing the personnel of a company. A manager manager persons,
> 
> >>> not identities.
> 
> >>>
> 
> >>> A computer system is not supposed to model the liver or a soul of a
> 
> >>> Person, but abstracts the properties that are relevant to the task.
> 
> >>
> 
> >> Well you said it.
> 
> >>
> 
> >>> A Person has a manager. An Identity does not.
> 
> >>
> 
> >> My local health service no longer calls people 'patients'. People who
> 
> >> use the services are called unsurprisingly 'service users'
> 
> >>
> 
> >> While I abhor the impersonal overtones of this particular bit management
> 
> >> speak it makes perfect sense in terms of describing the entity concerned.
> 
> >>
> 
> >> In the case you quote surely a manager manages Employees
> 
> >>
> 
> >> or
> 
> >>
> 
> >> An Employee *has a* Manager
> 
> >> A Manager manages one or more Employees
> 
> >> An Employee has one or more Roles
> 
> >> An Employee has an Identity (or many if you insist)
> 
> >> A Manager *is an* Employee
> 
> >> etc etc
> 
> >>
> 
> >> No mention anywhere of the class *Person*
> 
> >>
> 
> >> You state
> 
> >>
> 
> >> 'A Person may have more than one Identities' (sic)
> 
> >>
> 
> >> I'd prefer 'An Employee can have one or more Roles/Identities'
> 
> >>
> 
> >> A person with multiple identities doesn't really make sense does it?
> 
> >>
> 
> >> How do you identify someone with multiple identities???
> 
> >>
> 
> >>
> 
> >>
> 
> >
> 
> > Indeed i our model a Person can have at most one identity. I remembered
> 
> > wrong.
> 
> >
> 
> >
> 
> > But then the Employee. And a Manager? (We do not have a Manager, but
> 
> > Person has a property isManager).
> 
> >
> 
> > A Person may be a Manager, AND is an Employee as well. Your model does
> 
> > not work.
> 
> 
> 
> I think it does, read again, I said
> 
> 
> 
> An Employee *has a* Manager
> 
> A Manager *is an* Employee
> 
> 
> 
> > He has an Identity, and multiple User Accounts. He is a
> 
> > Person. Not an Employee. He may be an Employee, but the Owner of the
> 
> > business is no such. A Person is a generalization of these, no need to
> 
> > make the model too keen on details, too complicated. Or do we need a
> 
> > Boss class too?
> 
> 
> 
> Well in the first place Owner and Boss are two different concepts, in 
> 
> any case either the boss or the owner or both if they are different 
> 
> probably works for the company (even if he owns it, someone/thing has to 
> 
> pay him) in which case he/she is an Employee.
> 
> 
> 
> Don't forget, legally, here at least in the UK a (limited) company is a 
> 
> legal entity in it's own right, the company pays the wages, not the 
> 
> owner/boss/whoever ...
> 
> 
> 
> ... and are you really saying that you need Person as a generalization 
> 
> because the Boss is not an Employee ... not much of a reason is it?
> 
> 
> 
> You say you are managing the personnel of a Company. What other types of 
> 
> personnel are there apart from Employees.
> 
> 
> 
> -- 
> 
> Lipska the Kat©: Troll hunter, sandbox destroyer
> 
> and farscape dreamer of Aeryn Sun
> 
> GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26342

On 16/10/13 18:15, L. wrote:
> So I've read the signature: "Lipska the Kat©: Troll hunter".
>
> I'm trying to understand how a "Troll hunter" can be a troll. How this thing can be modeled using OO principles?

I'm trying to understand how someone who top posts expects to be taken 
seriously ... but still, let's take things slowly.

Are you one of those people who thinks that disagreeing with someone or 
espousing a theory that others may not agree with is a troll?

If you are, allow me to provide this link

http://en.wikipedia.org/wiki/Troll_(Internet).

Now you've read this, what encourages you to mark me down as a troll?

Secondly, how can what thing "be modeled using OO principles?"



-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26343

You criticized someone just because he named a class "Person". You said::

"How are you going to model consciousness, sentience, the 'mind', the 'soul'? let alone arms legs, eyes and teeth :-)"

IMO, a model is just a simplification of the reality. If I know someone is use my system and all I need to know is his/her name, I just need an attribute "name". Why do I need to model consciousness and the soul? When you asked things like that, I think you are trolling.

>> Are you one of those people who thinks that disagreeing with someone or 
>> espousing a theory that others may not agree with is a troll? 

I'm not. But your theory just doesn't make any sense. You have suggested a better class name. For example, Employee or User or Manager or whatever else. An Employee or a User has consciousness, but you don't see any problem naming a class "Employee" or "User". 

So, Person has consciousness (and other abstract attributes). So do and Employee or a User. And you think name a class Person is nonsense and name a class Employee or User is quite adequate. So, I might be trolling, right?



Em quarta-feira, 16 de outubro de 2013 15h01min37s UTC-3, lipska the kat  escreveu:
> On 16/10/13 18:15, L. wrote:
> 
> > So I've read the signature: "Lipska the Kat�: Troll hunter".
> 
> >
> 
> > I'm trying to understand how a "Troll hunter" can be a troll. How this thing can be modeled using OO principles?
> 
> 
> 
> I'm trying to understand how someone who top posts expects to be taken 
> 
> seriously ... but still, let's take things slowly.
> 
> 
> 
> Are you one of those people who thinks that disagreeing with someone or 
> 
> espousing a theory that others may not agree with is a troll?
> 
> 
> 
> If you are, allow me to provide this link
> 
> 
> 
> http://en.wikipedia.org/wiki/Troll_(Internet).
> 
> 
> 
> Now you've read this, what encourages you to mark me down as a troll?
> 
> 
> 
> Secondly, how can what thing "be modeled using OO principles?"
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Lipska the Kat�: Troll hunter, sandbox destroyer
> 
> and farscape dreamer of Aeryn Sun
> 
> GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#26345

On Wed, 16 Oct 2013 12:17:59 -0700, L. wrote:

> I'm not. But your theory just doesn't make any sense. You have suggested
> a better class name. For example, Employee or User or Manager or
> whatever else. An Employee or a User has consciousness, but you don't
> see any problem naming a class "Employee" or "User".
>
I think Lipska's right about this: a Person is simply too high a level of 
abstraction to be useful to many systems. When you boil it down, a Person 
would have relatively few attributes: birthday, name, gender and that's 
about it. The rest of what we know about a person is best modelled as 
relationships with other Persons or as objects with which a Person 
instance has Person-Has-X relationships.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#26350

On 10/16/2013 5:01 PM, Martin Gregorie wrote:
> On Wed, 16 Oct 2013 12:17:59 -0700, L. wrote:
>> I'm not. But your theory just doesn't make any sense. You have suggested
>> a better class name. For example, Employee or User or Manager or
>> whatever else. An Employee or a User has consciousness, but you don't
>> see any problem naming a class "Employee" or "User".
>>
> I think Lipska's right about this: a Person is simply too high a level of
> abstraction to be useful to many systems. When you boil it down, a Person
> would have relatively few attributes: birthday, name, gender and that's
> about it. The rest of what we know about a person is best modelled as
> relationships with other Persons or as objects with which a Person
> instance has Person-Has-X relationships.

Person is a very high level abstraction.

But in some applications it is all what is needed.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web