addRole() to user / removeRole() from user..

[imre-szekeres]

@GergelyVarkonyi

.. Ekkor mar tenyleg kell egy Service, amiben van UserService, RoleSerice, DomainAssignmentService..

@Deprecated UserLifeCycleService

@Deprecated UserHandler

UserHandlerLocal --> UserHandlerImpl -> @Deprecated registerUser(String username): User // nem kell, mert createUser lefedi + reusable -> @Deprecated addRole(long userID, String roleName): User -> @Deprecated removeRole(long userID, String roleName): User -> @Deprecated assignUser(long userID, String domainName): User

-> createUser(String username, String initialRole, String domainName): User
-> addRole(long userID, String domain, String role): boolean
-> removeRole(long userID, String domain, String role): boolean
-> assignUser(long userID, String domain, String role): User
-> deassignUser(long userID, String domain): User
-> removeUser(long userID): User
-> validate(User, String, boolean): Map<String, String>

tehat most a UserHandlerLocal igy nez ki:

@Local
public interface UserHandlerLocal {

    User createUser(User user, String initialRole, String domain);

    User removeUser(long userID)  throws Exception;

    boolean addRole(long userID, String domain, String role);
    boolean removeRole(long userID, String domain, String role) throws Exception;

    User assignUser(long userID, String domain, String role);
    User deassignUser(long userID, String domain) throws Exception;

    Map<String, String> validate(User user, String otherPassword, boolean isRegistered);
}

[imre-szekeres]

@GergelyVarkonyi

Szerintem erdemes lenne elgondolkodni itt azon, h kiprobaljuk a CQRS -t (Command Query Responsibility Segregation), mert A UserHandler nem biztosit listazast, arra neked kell UserService-t hasznalni, auth-ra is... egyenlore a validation van benne. Ellenben ez leaky abstraction, mert lehetoseget ad arra, hogy megkeruljek a Handler altal nyujtott business logic-t, (am is lehet, csak sokkal kezen fekvobb, ha kulon be kell szedni a Service -eket). Amit lehet:

1.: select logic-t berakni a UserHandlerLocal -ba
        + nincs masik class
        + egyszeru, mert nem kell masik Impl
        - ha csak keresni szeretnenk, => memory overhead, mert beszedi a tobbi Service-t is, holott csak UserService kene
        - nagyra duzzad a UserHandlerLocal es meg nagyobbra a UserHandlerImpl (vannak private cuccai is)

2.: Command - Query RS => kulon UserQueryHandlerLocal, UserCommandHandlerLocal
         /** xor csak UserQueryLocal UserCommandLocal ? **/
        + kevesebb code az osztalyokban => atlathatobb
        + UserQueryHandlerLocal -ban kb csak UserService kell => csak listazunk, akkor nem kell tobb Service a memoraiaba
        - tobb class
        - az olyan esetekben, amikor egy Controller query-command -t is csinal, akkor UserService duplicsation lesz, azaz duplan lesz a memoriaban..
        ? bottleneck meg lehet, mert Service -k nincsenek szetvalasztva... de pool-ban tobb van

[imre-szekeres]

@GergelyVarkonyi

amire gondoltam: /* talan az lenne a legjobb, ha elkezdenenk hasznalni ugy, ahogy van, es az elso olyan kontroller megirasa utan, ahol van CRUD, latnank h erdemes lenne-e atallni.. a Design Side -ra :D */

@Local
public interface UserQueryHandlerLocal {

    List<User> selectAll();
    User selectBy(long id);
    User selectBy(String username);

    Map<String, String> validate(User, String, boolean);
    boolean isAuthenticated(User user); // optional
}

@Local
public interface UserCommandHandlerLocal {

    User createUser(User user, String initialRole, String domain);
    User removeUser(long userID)  throws Exception;
    boolean addRole(long userID, String domain, String role);
    boolean removeRole(long userID, String domain, String role) throws Exception;
    User assignUser(long userID, String domain, String role);
    User deassignUser(long userID, String domain) throws Exception;
}

[ghost]

Igazából a Userservicet a Roleservicet és a hozzá kapcsolódó dolgokat a te gondjaidra bízom, és úgy használhatod ahogy neked kényelmes :D Ettől független lehet jobb lenne használni ahogy van és rögtön kiderül van e értelme szétszedni.

[imre-szekeres]

Ez azert is erint teged, mert valszeg a Workflow-nak, Project-nek is ilyen felulete lesz, ott is van mit varazsolni business logic-al. Es ha mar igen, akkor neked is kenyelmi kerdes lesz, h hogyan vannak a Handler -ek.

WebAppStartupListener -ben + LoginController -ben is fura kicsit, amikor behuzol UserHandler -t meg UserService -t. Majd megnezegetem igy is ugy is.

Akkor az alap API-ra rabolintasz? (interface + implementation segregation -re meg nev konvenciora?).. mert addig nem szerettem volna DomainHandler-t meg tarsait csinalni, amig question mark a dolog.

[ghost]

azt most nem értem miért handler és mi lett a userserviccel, de sztem egyelőre ne szedjük szét a kettőt, feleslegesnek tartom

[imre-szekeres]

A Service az alap Data Manipulation -t csinalja, ami EM -re tamaszkodik. A Handler pedig azokat az osszetartozo muveleteket, amelyek igenybe veszik a Service layer szolgaltatasait es magat a business logic-t valositjak meg. Pl a createUser() az letrehoz egy uj User-t a megadott Role-al a megadott Domain-ben (Ehhez kell UserService, RoleService, DomainService, DomainAssignmentService is). Azonban az assignUser() egy meglevo User -t ad egy meglevo Domain -hez. Az addRole() meglevo User -hez egy adott Domain -en belul ad Role-t.