I have some basic objects like Customer, Portfolio and ... with some association to other objects. I can easily display the required information in the web page by reading object values. The problem is that what do I do when the value associated with the object is calculated and returned by a method, a value that makes sense only in certain context and cannot be attached to the object as an instance variable? In this case if I have a list of say Users I have to pass the username of each user to the method to get the calculated value. This causes problem to keep the association while displaying the values in the page.
An example to make this clear:
An application provides the functionality for users to keep track of each others activities by letting them add whoever they want to a list. If this user performs a search on users there's the option to follow each returned user. I want to make sure this option is disabled for those user's that are already being followed. This functionality is provided by a method like isFollowed(String follower, String followee) which returnes a boolean. How can I associate this boolean values to each user in search result?
Solutions:
One thing I can think of is to add a followed instance variable to User class. But I don't think it's a good approach because this variable only makes sense in a certain context. It's not a part of User class in the domain.
The other way I can think of is to use Decoration or Wrappers in a way to extend the User class and add the attribute in the child class. But again what if I have several objects that need to be in the same context. In that case I have to extend all of them with the same boolean attribute in all classes.
I hope I could make it clear.
In principle, I don't see anything wrong with instance method on User: bool IsFollowedBy(User user).
Of course, this could lead to performance issues. If that is the case, you can create separate object for presentation purposes which bundles data from User and whether he is being followed by the user performing search. Then you can build query which retrieves all necessary data for such object in a single roundtrip to DB.
One solution is to avoid querying Entities (as in DDD/ORM) and query directly using subquery/join or even using some denormalized database. This is something CQRS pattern suggests.
Other solution is to do computations on application layer (how many Users can you show on the same page anyway), which is expensive but you can implement some caching techniques to make things easier.
Related
I am trying to figure out how to address this issue:
I have 3 tables with a many-to-many relationship.
Users *-* Roles *-* Permissions
I use a ORM to obtain data from them.
A method of my business layer must return users per permission, so I return objects with this class:
public class UsersPerPermission
{
public User[] {get;set;}
public Permission {get;set;}
}
But this class does not map to any table in the repository, it is something I generate from the existent tables. Where should this class live?
In other words:
Should I have a IRepository.GetUsersPerPermission()? And then that class should live in the repository.
Or should I have a IBusinessLayer.GetUsersPerPermission()? And then I have to invoke the CRUD methods in the repository?
It makes sense to put it in the business layer only, because the repository should just expose CRUD operations to tables... BUT, in order to execute this operation from the Business layer, I would have to execute several independent queries to get the data and create the 'UserPerPermission' class. In the other hand, if I place it in the repository, I can get that information in one shot using grouping.
Thanks!
PS: What is the name of this intermediate objects? 'transformations'?
In DDD, most entities and value objects should correspond to identified domain concepts that are part of your ubiquitous language. I usually try to limit many-to-many relationships and artificial association objects as much as possible. Eric Evans describes a few techniques allowing that in his book. When I have to create an association object, it must have a meaningful name with regard to the domain, basically I never name it Class1ToClass2.
In your scenario, it's even more artificial since your object :
Redundantly models an association that already exists (indirectly) in the original model.
Has a name that doesn't reflect any particular business concept.
Note that this kind of object wouldn't be useless if we were in the presentation or application layer as it could come in handy to have a structure containing exactly what is displayed on the screen (DTO). But I'm talking about the domain layer here, which should be devoid of such composite objects.
So I wouldn't create a UsersPerPermission class in the first place. If what you want is a list of users and User is an aggregate root, just create a GetUsersByPermission() method in UserRepository. It doesn't mean that you can't have a GetUsersByPermission() method in an application service as well, if it matches a use case of your application (a screen that displays the details of one permission and the list of users with that permission).
I agree with guillaume31 that there is no need to introduce a domain object "UsersPerPermission" to support a single use case.
There are two ways you can implement your use case using existing domain classes "User", "Role" and "Permission".
Solution one:
Assume you have: Permission --> Role --> User
Arrow denotes navigability. A Permission has association to a list of Roles and a Role has association to a list of Users.
I would add a method GetPermittedUsers() : List<User> to the Permission class, which is trivial to implement.
Th UI logic will invoke GetPermissions() of PermissionRepository then call GetPermittedUsers() on each Permission.
I assume that you use a ORM framework like hibernate(Nhibernate) and defines the many-to-many relationships correctly. If you defines eager loading for Role and User from Permission, the ORM will generate a query that joins Permission, Role and User tables together and load everything in one go. If you defines lazy loading for Role and User, you will load a list of Permissions in one query when you call PermissionRepository, and then load all associated Roles and Users in another query. Everything is load from database with up to three queries maximum. This is called a 1+n problem which most ORMs handle properly.
Solution two:
Assume you have: User --> Role --> Permission
Arrow denotes navigability. A User has a list of Roles. A role has a list of Permission.
I'd add getUsersByPermissions(List<long> permissionIds) : List<Users> to the UserRepository, and add getPermissions() : List<Permission> to the User class.
The implementation of the UserRepository need to join the User, Role and Permission tables together in a single query and load everything in one go. Again, most ORMs will handle it correctly.
Once you have a list of Users, you can create a method to build a Map<Permission, List<User>> quite easily.
To be honest, I muck like the solution one. I avoid to write a complicate method to convert a List of Users to to a map of Permission and Users, hence I don't need to worry about where to put this method. However solution one may create cyclic relationship between User, Role and Permission classes if you already have navigability in another direction. Some people don't like cyclic relationship. I think the cyclic relationship is acceptable even necessary sometime if you user cases demand it.
In a similar context I used a query method in a domain service that returns something like an
IEnumerable<KeyValuePair<PermissionName, IEnumerable<Username>>>
By using the KeyValuePair<> I avoided to pollute the domain model with an artificial concept (like UsersPerPermition). Moreover such a structure is immutable.
I didn't used a query method on the repository because, in my context, no entity was coupled with the other. So it wasn't matter for any of the repositories.
However this solution is useful for your GUI, if and only if you modelled correctly the identifiers of your entities (in your example both Permissions and Users are entities).
Indeed if they are shared identifiers that belong to the ubiquitous language that your users understand, they will be enough without further descriptions.
Otherwise you are just building a useful DTO for your GUI. It does not belong to the domain thus you should use the simplest possible thing that works (an ADO.NET query? something even simpler?).
Indeed, in my own scenario both the GUI and the domain used such a service (the GUI showing a preview of an elaboration).
In general, the domain model must mirror the domain expert's language, capturing the knowledge relevant to the bounded context. Everything else must be outside the domain (but most of time can be expressed in terms of the domain's value objects).
A core piece of the application I'm working on is allowing the user to explore a complex dataset by progressively add search terms. For example, you might start with a free-text search, then progressively add (or remove) some facetted search terms, move a slider to constrain some dimension of the returned results, etc.
Conceptually, it seems to me that the user is incrementally defining a set of constraints. These constraints are used to search the dataset, and the rendering of the results provides the UI affordances to add further search refinements. So building this in Rails, I'm thinking of having one of the models be the current set of search constraints, and controller actions add to or remove constraint terms from this model.
Assuming this is a sensible approach (which is part of my question!), I'm not sure how to approach this in Rails, since the search is an ephemeral, not persistent, object. I could keep the constraints model in the session store, but it seems rather a complex object to be marshalled into a cookie. On the other hand, I could put store the constraints model in a database, but then I'll have a GC problem as the database fills up with constraint models from previous sessions.
So: how best to build up a complex interaction state in Rails?
Here's some pointers
create a class XxxSearch with accessors for all the search facets: keywords, category, tags, whatever. This class should be ActiveModel compatible, and it's instances are going to be used in conjunction with form_for #xxx_search. This class is not meant for persistence only for temporaryly holding search params and any associated logic. It may even act as a presenter for data: #xxx_search.results, or implement search data validations for each faceting step.
incrementaly resubmit the form via wizard technique, or even ad-hoc data insertion on a large form.
allways submit the search via GET, as such:
the search is bookmarkable
you can chain the params to pagination links easily like: params_for(params[:search].merge(:page => 3))
you need NOT use the session, the data is forwarded via GET params, as such:
can keep using cookie session store
escapes you from a lot of headaches when the last search is persisted and the user expects a new search context (I say this from experience)
I had to solve this problem for several apps so I wrote a small gem with a DSL to describe these searches:
https://github.com/fortytools/forty_facets
Let's pretend we're talking about an HTML complaint form, one field of which is a product list from the company catalog.
I gather that validation usually (always?) goes in its own class.
I also gather that it's good practice to have gateway classes which can handle all the database queries internally, so when I save my complaint from my complaint form I don't have to worry about the database details.
But what about validation that requires accessing the database - for example checking that the product is actually a product we have (and not someone tampering with the form). This can only be done by finding a match in the database... but my database is abstracted behind my gateway.
Do I add validation logic to my gateway? Do I create validator gateway classes? Do I empower my validator with database logic?
EDIT - attempt to clarify...
customer clicks link to complaint form
HTML complaint form is built with a <select><item></item></select> dropdown with X products from our fictional company catalog
Customer completes form and Submits // Wiseguy alters HTML so product is "Schweddy Balls" and submits
Form class validates simple things like date, all required fields have data, email address, etc.
at step 4, in order to validate that the product being complained about is legit, you'd have to hit the database's product table to see if it's still a valid datapoint. Should that logic go in the form class, the gateway class, or somewhere else? putting it in the form class breeds dependencies, does it not?
Validation should, oddly enough, not be done directly through a Validation class. A model object's class (in this case probably Complaint) should include the Validation class and the validations should be done in there. Since the Complaint has access to all Complaints, validation methods can use the methods of the Complaint class, or call another model class if needed.
When you say "gateway" to the database, I believe you're talking about on Object Relational Mapping (ORM), which allows model objects, like a Complaint, to abstractly talk to the database. The ORM should have no knowledge of the structure or specifics of the application, it should only be an abstract API for objects to communicate to the database or other backend.
Surely my response does not cover everything, so further questions/clarifications welcome.
It's usually good practice to store valid data, only. So, one necessarily writes a validator on the server-side to ensure that requests are valid and only valid data gets put into the database, and as an optimization one typically validates on the client side (e.g. in JavaScript) so that the user is informed of invalid input without needing to submit the form and without needing to make a roundtrip. Doing the validation as part of the database write, allows subsequent reads to be done trivially with no checks.
I don't know the specifics of what counts as "valid" for you, but you can probably save a lot of database lookups with caching. Perhaps you could give some more information about your requirements?
Let's say we have "User" and a "Hotel" model classes. I'd use a User_Mapper and Hotel_Mapper to load/save/delete etc. I want to then have the user be able to mark their "favourite" hotels. In the database I have my user_favourite_hotels table which is a simple link table along with say a field for subscribing to hotel updates.
When listing out the user's favourite hotels, how would you expect this to work from an API point of view? A part of me thinks that this should be a "findFavouritesByUserId" method on the Hotel_Mapper, but other than saying it "feels" right - however a colleague suggests that the "favourites" is owned by the user and should therefore be on the User_Mapper.
Perhaps I should have a User_Hotel_Favourites_Mapper? I was thinking of incorporating the "favourites" data in to the User object so it's saved and loaded whenever the User object is. I'm not sure whether it'd be better to split it out in to it's own object and mapper however.
I'd appreciate any advice on how best to setup the API for the above and any pros/cons/experiences.
Thanks very much,
James.
This (admittedly retired) patterns&practices guide to designing data tier components suggests that you put the method in the mapper of the type of object that you're getting back from the call.
If you have methods that return a particular type of business entity, place these methods in the Data Access Logic Component for that type. For example, if you are retrieving all orders for a customer, implement that function in the Order Data Access Logic Component because your return value is of the type Order. Conversely, if you are retrieving all customers that have ordered a specific product, implement that function in the Customer Data Access Logic Component.
So, in your example, it would go in the Hotel Mapper as it is returning Hotels.
If you want to store favorite hotels for the user, you are using the UserMapper, which notices that domain object for User has changes favorites, and updates both tables for users and for user_favorite_hotels ( you just need the hotel IDs ).
When you are retrieving favorite hotels of some user, you use HotelMapper and set filter to be based on User, because you will be working with instances of Hotel.
Considering that this was asked more than 2 years ago, I'm not sure if an answer matters to you now. But here's what I think anyway.
If User could have multiple types of favourites (including Hotels), it may make sense to have a UserFavourites abstraction to cover all possible types of favourites. UserFavourites could expose a getItems() method to get the underlying Favourites.
This could be managed with the help of a manager class to return the appropriate Favourites object(FavouriteHotels for example) on which the getItems() method can be called.
Struggling with a decision on how best to handle Client-level authentication with the following model hierarchy:
Client -> Store -> Product (Staff, EquipmentItem, etc.)
...where Client hasMany Stores, Store hasMany Products(hasMany Staff, hasMany EquipmentItem, etc.)
I've set up a HABTM relationship between User and Client, which is straightforward and accessible through the Auth session or a static method on the User model if necessary (see afterFind description below).
Right now, I'm waffling between evaluating the results in each model's afterFind callback, checking for relationship to Client based on the model I'm querying against the Clients that the current User is a member of. i.e. if the current model is Client, check the id; if the current model is a Store, check Store.clientid, and finally if Product, get parent Store from Item.storeid and check Store.clientid accordingly.
However, to keep in line with proper MVC, I return true or false from the afterFind, and then have to check the return from the calling action -- this is ok, but I have no way I can think of to determine if the Model->find (or Model->read, etc.) is returning false because of invalid id in the find or because of Client permissions in the afterFind; it also means I'd have to modify every action as well.
The other method I've been playing with is to evaluate the request in app_controller.beforeFilter and by breaking down the request into controller/action/id, I can then query the appropriate model(s) and eval the fields against the Auth.User.clients array to determine whether User has access to the requested Client. This seems ok, but doesn't leave me any way (afaik) to handle /controller/index -- it seems logical that the index results would reflect Client membership.
Flaws in both include a lengthy list of conditional "rules" I need to break down to determine where the current model/action/id is in the context of the client. All in all, both feel a little brittle and convoluted to me.
Is there a 3rd option I'm not looking at?
This sounds like a job for Cake ACL. It is a bit of a learning curve, but once you figure it out, this method is very powerful and flexible.
Cake's ACLs (Access Control Lists) allow you to match users to controllers down to the CRUD (Create Read Update Delete) level. Why use it?
1) The code is already there for you to use. The AuthComponent already has it built in.
2) It is powerful and integrated to allow you to control permissions every action in your site.
3) You will be able to find help from other cake developers who have already used it.
4) Once you get it setup the first time, it will be much easier and faster to implement full site permissions on any other application.
Here are a few links:
http://bakery.cakephp.org/articles/view/how-to-use-acl-in-1-2-x
http://book.cakephp.org/view/171/Access-Control-Lists
http://blog.jails.fr/cakephp/index.php?post/2007/08/15/AuthComponent-and-ACL
Or you could just google for CakePHP ACL