First a little background. I'm an experienced software engineer and think himself have some clues on software development and software design. Hope you still agree on this after your reading. Also I've been working full time on a DNN product for 6 months and I'm a happy user. So please don't take this thread as an offence.

 

 

Currently DNN core organizes its most business logic in controller classes, which consist of static methods. Info classes are used as dummy classes to pass information around. IMHO, this is not more procedural way than OOP . A software class should have both behavior and information and they shouldn't be separated, just like us human beings. For example, in an accounting department, there are account assistant, account receivable (AR), account payable (AP) and department manager. Everyone has his own professional knowledge and instructions or rules to follow (information) and do things differently (Behavior). an AP position is different from an AR position not only because they do things differently, but also because they require different professional knowledge, different accounting rules and different input from outside, or we can say In essence AP and AR are different because they do things differently, requires different accounting knowledge, follow different accounting rules. Information and behavior are equally to important and are two inherent parts of two accounting job.   There is no point to separate these two and no way to separate them if we want accounting things work.  

 

 

Separation of information and behaviors in software classes cause problems too. When we try to extend a class, we have to extend both info and a controller class, which is a real pain when you have to deal with complex domain model that usually has a lot of inheritances. As a result, the number of classes increase a lot and you have to pass info classes around to do the simplest things, which in true cause more headache.

 

 

When it comes to business logic, there are at least two types of them (forgot when and where I learnt the idea, but it works for me). Some business logic belongs to a single class, and some business logic is related to specific business process or part of it. The latter should be in business process classes not controller classes. Usually business process classes delegate its responsibility to other domain classes and coordinate between them to get job done. Thus, business process classes are perfect candidates for transaction control. Putting different concerns into a business class is to ask for trouble. The result is business classes are unnecessarily coupled to other classes and hard to understand, maintain and improve. Sometimes the process logic goes to code behind file when developers find it belongs to nowhere. IMHO, DNN core architecture misses another layer above current business layer- I call it business process layer, which is a facade of business layer and deals with business process. This way we can organize business logic in more understandable and reusable way. One example is in CreateUser method of a UserController class and UserCreateCompleted in manageusers.ascx.vb, user registration logic can be improved easily if there is another abstraction on top of current business layer. Module developers can then call the method in business process class and reuse logic in both UserController class and code behind file.

 

 

That's all for today. Thanks for reading and I will write more when I got time.

 

Frank