Hello This is my first post in this forum. I have not begun to develop my first application with LLBLGEN PRO yet, and I have been reading the documentation, and reading the posts in this forum. I have already read posts about inheritance, and extending the classes, but I have some unclear points.

I would like to build an apllication based on Domain Model, that I think will make it easier to develop and mantein. I have just read "Refactoring" from Martin Fowler and think this model will help me developing a better designed application.

I know Frans prefers the Manager Model, but I think that when I´ll see some methods in the manager class I will think in "Move Method" refactoring to move the method where the data is And I always have the possibilty of developing a manager class if I think so. A mixed model sounds good.

My question, now, is about what is the best template form making this. I know that I can subclass with adapter template, but It seems that I would finish deriving all the classes. It seems to much work in a mid to big sized application. I think that selservicing with two classes allowed me to write all the behaviour in the derived Entity class, but I have no way to derive this classes more and make possible the implementation of 1 table- n classes inheritance. I think I would like something like a "Two classes Adapter Template" where I can extend the classes with or without deriving to another subclass.

Frans, excuse me if these are subjects already debated, but I would like to get more ideas or information about them.

And thanks for the forums and all the support you give to the product.

Juan M. Cervera

Hi Juan, and welcome aboard

If you haven't checked out these threads, I would: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=802 http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=905 http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=834

IMHO, the Adapter rocks and I think it is worth the little amount of extra work to use it.

Happy coding (or is the Codding?),

Fishy

jmcervera wrote:

I would like to build an apllication based on Domain Model, that I think will make it easier to develop and mantein. I have just read "Refactoring" from Martin Fowler and think this model will help me developing a better designed application.

Ok

I know Frans prefers the Manager Model, but I think that when I´ll see some methods in the manager class I will think in "Move Method" refactoring to move the method where the data is. And I always have the possibilty of developing a manager class if I think so. A mixed model sounds good.

What fits the problem and what fits you is what's best So go for the pragmatic approach: too many people think in all-or-nothing solutions and miss the often better solutions of applying some pragmatism here and there. For example in the inheritance area: Fowler / Evans want to inherit classes a lot. This can lead to severe problems which can be solved by switching to 'roles' applied to objects. For example: Person <- Customer and Person <- Employee. What if the Employee is also a customer? You can also solve this by using Person with the role 'Customer' and the role 'Employee', making the system more flexible.

My question, now, is about what is the best template form making this. I know that I can subclass with adapter template, but It seems that I would finish deriving all the classes. It seems to much work in a mid to big sized application. I think that selservicing with two classes allowed me to write all the behaviour in the derived Entity class, but I have no way to derive this classes more and make possible the implementation of 1 table- n classes inheritance. I think I would like something like a "Two classes Adapter Template" where I can extend the classes with or without deriving to another subclass.

You can add code to the adapter classes in two ways: 1) use the 3rd party template which generates derived classes for all entities (see the 3rd part section on the website) 2) use a custom include template. This is a new feature in v1.0.2004.1, and which allows you to define a template file which is bound to a predefined templateID by you through a custom template config file. In that template file you define which code should be included in which entity class, so you can add methods for customer to the customer entity and other code to the order entity class for example.

However I'd also look in the more flexible approach where inheritance is dropped for roles. This is often the solution to have Multiple Inheritance behavior in a single inheritance environment as well.

Thank you Fishi.

I will check the threads that you give me.

I am thinking in using the adapter template for my application, and I pretend to extend the entity classes only with behaviour in most cases. It is for this that I was thinking if this would not be too much work, and it will be better to use the Two-Classee Selfservicing template where I have already the derived subclasses.

But it seems that a third-party template can help. I´ll give it a try.

Juanma

Thanks Otis.

Otis wrote:

What fits the problem and what fits you is what's best. So go for the pragmatic approach

Yes. Now I am reading "The pragmatic programmer"

For example in the inheritance area: Fowler / Evans want to inherit classes a lot. This can lead to severe problems which can be solved by switching to 'roles' applied to objects. For example: Person <- Customer and Person <- Employee. What if the Employee is also a customer? You can also solve this by using Person with the role 'Customer' and the role 'Employee', making the system more flexible

.

This is not all clear to me.

How do you apply a role to an object? Implementing the state pattern or the strategy pattern (GoF) for Customer and Employee in the class Person. In any case, you have to extend the class.

Another option, instead of using subclassing would be to use delegation, no? And we will write the classes Customer and Employee delegating to a Person object. This could be an option.

But I am not trying to subclass the entities only for doing it, the problem is that I have to do it, if I want to write behaviour in them and I am using adapter. Two-Classes Selservicing seems better for this, but I will prefer to stay with Adap`ter.

You can add code to the adapter classes in two ways:

1) use the 3rd party template which generates derived classes for all entities (see the 3rd part section on the website)

This sounds very good. I think this is what I am looking for, ... and I have tried, but I have no file generated under the EntitySubClasses directory. Which will be the problem.? Maybe I have not installed well the templates. I don´t know.

2) use a custom include template. This is a new feature in v1.0.2004.1, and which allows you to define a template file which is bound to a predefined templateID by you through a custom template config file. In that template file you define which code should be included in which entity class, so you can add methods for customer to the customer entity and other code to the order entity class for example

. It sounds too complicate, and not very flexible, but perhaps I am not understanding.

Well Otis, thanks for you time. Only one thing more. Would it be possible to provide the forum with a printer friendly option for a thread? For me, it woul be easier to learn reading in paper, because my english is not so good.

Thanks

Juanma

jmcervera wrote:

For example in the inheritance area: Fowler / Evans want to inherit classes a lot. This can lead to severe problems which can be solved by switching to 'roles' applied to objects. For example: Person <- Customer and Person <- Employee. What if the Employee is also a customer? You can also solve this by using Person with the role 'Customer' and the role 'Employee', making the system more flexible

.

This is not all clear to me.

How do you apply a role to an object? Implementing the state pattern or the strategy pattern (GoF) for Customer and Employee in the class Person. In any case, you have to extend the class.

True, but you could add a property through an include template. Otherwise you require a new type which requires database data as well. You can now for example add the role data to the person table

Another option, instead of using subclassing would be to use delegation, no? And we will write the classes Customer and Employee delegating to a Person object. This could be an option.

Indeed

But I am not trying to subclass the entities only for doing it, the problem is that I have to do it, if I want to write behaviour in them and I am using adapter. Two-Classes Selservicing seems better for this, but I will prefer to stay with Adap`ter.

If you generate a subclass for every entity using the 3rd party template which does this for you, you're set.

You can add code to the adapter classes in two ways: 1) use the 3rd party template which generates derived classes for all entities (see the 3rd part section on the website)

This sounds very good. I think this is what I am looking for, ... and I have tried, but I have no file generated under the EntitySubClasses directory. Which will be the problem.? Maybe I have not installed well the templates. I don´t know.

Do you choose the correct configuration and template set configuration?

2) use a custom include template. This is a new feature in v1.0.2004.1, and which allows you to define a template file which is bound to a predefined templateID by you through a custom template config file. In that template file you define which code should be included in which entity class, so you can add methods for customer to the customer entity and other code to the order entity class for example

. It sounds too complicate, and not very flexible, but perhaps I am not understanding.

This is actually very easy But indeed requires some knowledge of the code generator, its template system etc., so subclassing the entity classes is easier then.

Would it be possible to provide the forum with a printer friendly option for a thread? For me, it woul be easier to learn reading in paper, because my english is not so good.

Added to the list of forum updates to be added

Otis wrote:

If you generate a subclass for every entity using the 3rd party template which does this for you, you're set.

jmcervera wrote:

This sounds very good. I think this is what I am looking for, ... and I have tried, but I have no file generated under the EntitySubClasses directory. Which will be the problem.? Maybe I have not installed well the templates. I don´t know.

Do you choose the correct configuration and template set configuration?

You're right. I was not selecting the correct template set.

Now I have my EntitySubClasses generated. I see them, but I think I will still have some problem. I think that these subclasses have to be regenerated every generation of the project. They will be overriden, and I will have to write my specific behaviour again, no? Is it right, or they are preserved like in the Two-classes selfservicing model? It's a difficoult decission. If I think in adding specific behaviour to the classes (for example a calculated total field for invoices), I would choose Two-Classes SelfServicing model. If I think in the possibility of subclassing to get 1 table-n classes inheritance, orI think in implementing a remote service tho provide the objects I will use Adapter. All is important.

What are most of the people doing? Nobody goes with a pure Domain Model? How the do it?

These are the things that I am studing. The thing I have no doubt at this moment, is in using the entities in the GUI and using databinding, althought in my GUIs I try to get the logic and the presentation the more isolated I can. (humbled dialog pattern)

Otis wrote:

jmcervera wrote:

Would it be possible to provide the forum with a printer friendly option for a thread? For me, it woul be easier to learn reading in paper, because my english is not so good.

Added to the list of forum updates to be added

Thank you very much Otis.

I have read some of the Martin Fowler book - it seems a good book and all the arguments make good sense to me, but the problem that I had with it was that there isn't much of of the logic he often uses in is examples in my application.

99% of my app gets data, formats it slightly, maybe adds some more data from somewhere else, and then passes it to the presentation layer. There is no "Calculating revenue" for me much....

With that in mind and also the fact that we come from a COM/DNA background, we stuck with something not too dis-simillar - with the BL "managing" the main app logic. I have a legislation object, and it gets single entities and collections, and passes back datatables and entity collections. Does this map to "table model"? I suppose it does - although I see more similarities with "service model".

Hmmmm, whatever model it is, so far it works well for us I was apprehensive when I started developing my app (hence about 100000000 postings from me in this forum area) - I was worried that I would miss out on cool OO featues because I didn't think i was going "domain model". But now I agree with Frans, theres lots of documented solutions, but the best solution is the one that works with your application.

But now I agree with Frans, theres lots of documented solutions, but the best solution is the one that works with your application

. Ok.
It´s better no to fight against the tools you use, and use them in their most productive manner. I am agree.

Thanks for your replies.

jmcervera wrote:

Otis wrote:

If you generate a subclass for every entity using the 3rd party template which does this for you, you're set.

jmcervera wrote:

This sounds very good. I think this is what I am looking for, ... and I have tried, but I have no file generated under the EntitySubClasses directory. Which will be the problem.? Maybe I have not installed well the templates. I don´t know.

Do you choose the correct configuration and template set configuration?

You're right. I was not selecting the correct template set.

Now I have my EntitySubClasses generated. I see them, but I think I will still have some problem. I think that these subclasses have to be regenerated every generation of the project. They will be overriden, and I will have to write my specific behaviour again, no?

No that's not the case The derived classes rely on their base classes for hte things which can change, so after you've generated the derived classes, you can stick with the normal adapter configurations to generate your code, which will only generate the base classes again. (set the adapter generation config of choice in the preferences)

Is it right, or they are preserved like in the Two-classes selfservicing model?

Preserved, as you choose for a different generator configuration next time you generate code, which means you don't overwrite the derived classes. Only when you alter entities you probably need to. Mark all classes which you don't want to be overwritten as read-only in windows.

It's a difficoult decission. If I think in adding specific behaviour to the classes (for example a calculated total field for invoices), I would choose Two-Classes SelfServicing model. If I think in the possibility of subclassing to get 1 table-n classes inheritance, orI think in implementing a remote service tho provide the objects I will use Adapter. All is important.

True. I'd add the total field through an include template, as these are merged at generation time and therefore your code will never run the risk of being overwritten.

What are most of the people doing? Nobody goes with a pure Domain Model? How the do it?

Pure domain model is IMHO not that practical. You want some behavior with an entity but only very little. Big business rules span multiple entities and where to place these? Manager classes can solve this very easily. What's more important also is: you can model manager classes after real-like processes you have to automate with the software in the first place. WIth the domain model you can't. Evans also acknowledges this by stating that a translation language is required for the domain model to do this properly or better: to get that connection between functional design / research and actual code.

Hi,

Otis wrote:

Pure domain model is IMHO not that practical. You want some behavior with an entity but only very little. Big business rules span multiple entities and where to place these?

I think the answer is that, distributed across the multiple entities.

Manager classes can solve this very easily. What's more important also is: you can model manager classes after real-like processes you have to automate with the software in the first place.

OK. They represent the use Use Cases that express the requirements of my application.

WIth the domain model you can't

Evans also acknowledges this by stating that a translation language is required for the domain model to do this properly or better: to get that connection between functional design / research and actual code.

I have not read the book yet. It seems that everybody is talking about it in the blogs, I will write this title on my list. But I agree, this translation are the manager classes you talk, the application layer, an api to the domain model. The difference is only how much code we put in each side.

And ... After all, I have get a lof of knowlege and ideas, in this thread. I am sure I will get a good job done with LLBLGEN in my first time, also I know that some of my decissions will change for the second.

Thanks.

Juanma

I am somewhat of a late commer to this conversation but I just wanted to add some of my thoughts. I am not saying that you should not use a domain model, simply pointing out some things to consider.

Use interfaces whatever you do Through trail and error, as well as many long nights spent refactoring mini-frameworks, I have come to prefer seperating interface from implementation. The clients and/or consumers are typically programmed against an abstraction, not a particular implementation.

When you use inheritance and abstract class hierarchies, you loose some things that I think are important. With an abstract class and sub classes there is not really a distinct and firm separation between implementation and the interface. With interface based development ther is.

To quote the Programming .NET Components Book by Oriley, "The more explicit and well defined a contract is, the less likely it is that there will be more conflicts down the road regarding exactly what the class providing the service is required to do"

Abstract classes can have implementation. It is much easier to break a contract using abstract class inheritance than if you were implementing an interface.

Another great point to using interface based development VS. thick class hierarchies is due to the fact that a class can implement multiple interfaces, and you can create composite interfaces that derive from other interfaces.

Another thing to note about class hierarchies is that if you are going to do this, atleast make sure that the abstract object implements an interface. This will guarantee that all sub classed objects conform to the contract.

Domain objects with regards to a distributed app Thick class hierarchies are typically not marshalled well. As a matter of fact, if you tried to interop an object to COM (i.e. using COM+) your nice class hierarchy will be flattened and I beleive that the abstract members go away. If you need to support Interop, you should proceed with caution when considering thick class hierarchies.

On the otherhand, you could use a services layer and just marshal the services layer and thus your domain objects would stay intact and still be able to do all of the heavy lifting.

In regards to code reusability Domain objects are typically specialized to a business operation, or they become bloated. A finely tuned set of interfaces could allow you to build new objects faster, using your existing interfaces, whithout having to refactor code in the domain or extenting an existing domain via inheritance.

** How I use domain objects with respect to LLBLGen** What I am considering a domain object is probably more along the lines of a data transfer object.

Take the following scenario: I have a payment Service that accepts various types of payments from varous systems. After payments are received by the services layer they are re-directed to a an object that invokes the implementation required to deal with the specific payment in question. Some payments need to go to clearing houses before they hit the AR, some need to go to the AR dirctly and await approval before moving to the GL, and some hit the AR immediately and post to the GL immediately.

I will create a payment object, and attach LLBLGen entitites to it. I will attach as many entities as required and ship the payment object off to the facade (services layer). Then I will pass the payment from the facade, into a controller, that invokes the specific strategy for the transaction type. The controller contains the logic to determine the transaction type. The strategy might involve one or more other object that do specific peices of the implementation that is interacting with different systems.

When its all said and done with, the transport or domain object goes away because the transaction is done. Now the process can repeat as needed. I also prefer a stateless architecture that is very granular. This means that the actions taken by the consumers dictate what operation is completed, and that the consumers dont need to tell the domain object how to act, because there is already code written to handle it.

I hope you found this somewhat readable. Cheers.