Re: [xwiki-devs] Thoughts on new model proposal

Hi Vincent, It's good to have you back :) On 11/13/2012 08:15 AM, Vincent Massol wrote: This is not maintainable in the long term. Which is why we're here... Aka the controller is mixed with the model. What if you wanted to deserialize a bunch of documents in an XAR, add an object to each one of them and then reserialize them? I tried to do this at one point and found out that the only two options were manipulating the XML or bringing up an entire wiki because XWikiDocument depends on everything. Another case is when storage changes so radically that the storage API needs to change. Imagine for that JDBC becomes able to do asynchronous load and store with a callback. In order to take advantage of this improvement we would need to find all of the places where code synchronously calls saveDocument() and replace them with code that understands callbacks. This isn't too bad if all of the controller code is severable from the model but if the model calls into the store and it offers store APIs to it's consumers (basically everything depends on the model), something as simple as implementing a (radically) new store will land us back here talking about model 3.0. Even just making a change to the store implementation will break this model, how do I load a document from one store and save it to another if the document is aware of it's store? Taken another way, the store has to depend on the model because it handles these objects in order to persist and load them, to make the model include APIs which depend on the store creates a cyclical dependency loop, the basic building block of spaghetti code. I took the time to read this all over again very carefully and with a clear mind. I have come to the same conclusion about Fowler's arguments as before but I have also noticed that he does not support your idea of mixing Document and storage logic. Quoted from your martinfowler.com link: "It's also worth emphasizing that putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities. The logic that should be in a domain object is domain logic - validations, calculations, business rules - whatever you like to call it." Now for completeness, although this is off the topic of the model, I will address the flaws in Fowler's argument. His most prominent point is "it's not really object oriented" which is an obvious case of http://en.wikipedia.org/wiki/Law_of_the_instrument "Give a small boy a hammer, and he will find that everything he encounters needs pounding." having once been a small boy with a hammer, the quote still makes me giggle.. The point is that sometimes objects make huge sense, other times procedures, sometimes functional programming works best, sometimes a combination of the 3 or something else entirely. The only "one true way" is to use the right tool for the job. Aside from the "only true way" argument, Fowler doesn't offer much to back his claim that lean objects are bad. "The primary cost is the awkwardness of mapping to a database, which typically results in a whole layer of O/R mapping" I suppose this was written before Hibernate/DN/Spring/etc existed making this trivial so it wasn't wrong when he wrote it. Now aside from the zealotry rubbish and the ORM mapping issue which nolonger exists, I don't see any reasons that lean objects are bad and finally I reject the word "anemic" as a weasel word in this context as it is clearly a distraction from the issues. Now back to the model: The wiki article you linked to makes a few good points about the value of adding code to your objects. Validation and functions like clone() make perfect sense inside of an object. What makes no sense is having references beyond the object's scope to things like serializers, name resolvers and storage. I think a good rule is that I should be able to create a model object using new Document() and have it fully functional without the need for any other part of the wiki. Of course this can't be implemented without the document containing a reference to the store, back to the above issue. It's a global variable which points to a thread local. Even though only that thread can see it, the entire codebase can access it so from a maintainability standpoint, it's a global. It's hard to define but I can give an example: Module A puts a few things into the context and module B, C, and D take them out and use them. Now you want to remove A and you refactor everything which explicitly depends on it and pull it out and everything explodes because there are hidden dependencies via other modules expecting things to be placed in the context. As long as your context is a Map<String, Object> there will always be this possibility. Dependency injection cleverly avoids this issue by using a Map<Class, Object> where you have to have a reference to the class before you can have an object of that class so by controlling access to the class, you control how far the implementations leak out. ok Another global var which will lead to more "saveAsAuthor()" and "saveWithProgrammingRights()" etc. which swap around the global variable around before and after doing the operation. This global var will lead to more try/finally traps where the storage is swapped around for one operation. The fact that you're adding a ffu map to a function indicates that it should be a function of the store, not of the model. That way if the store is changed the parameters can change. We can wrap the generic thingstore with a documentstore class/interface which takes precisely the parameters we want and prepares the document for storage. And Fowler said mixing model with storage is not what he means.. Ok, that's valid. Hmm if session is going to be aware of all things which have been altered by it then it must provide them. If I get a document from the Server then call save() on the session and that document is saved, that is two apparently unrelated objects having an effect on each other which is nonsensical. I'm not sure how much use there will be for that but one approach is to pass the session to the save functions and this would communicate the user to save as and the store to save in, it would however tie your hands a little bit. What issue is this? Usually the issue I run in to is I have to bring up almost a whole wiki just to instantiate an XWikiDocument. Anyway I'm sure there are other ways which respect the API consumer's right to use their own implementation of Space or Document. +1 for passing the user to any call which needs permissions checking. My last question is how do you differentiate this from the oldcore model? In order to make the case that we need to have a new model, we need to prove that in 8 years this isn't going to be the same as the oldcore is now. Thanks, Caleb