seperating business logic

[developerinlondon]

I am trying to find a way to seperate the business logic away from our codes so that it stays independant of any languages. At the moment its written in php and has lots of 'if's, regular expressions, conditions, exceptions of all kinds to work out various values. I am planning to move it into Java but seperate out the logic first. Does anyone know of a way I might go forward with this? I was thinking there might be some xml business logic protocol which lets you work out logics using an external xml file...

 

[timw]

Then the XML forum (forum426) would be a better place to post, no?

 

[developerinlondon]

strange... i just tried posting on that forum twice now but it doesnt seem to do anything...

 

[timw]

Maybe they jnew you were coming

 

[developerinlondon]

haha got it working now:

http://tek-tips.com/viewthread.cfm?qid=1029321&page=1

hasta la xml.

 

[timw]

Anyway, it sounds like 'over-engineering' to me.

 

[developerinlondon]

not quiet. the business logic is getting more and more complicated everyday as we are adding rules, exceptions of all kinds to it regularly. We have to go through lots of PHP code to figure out whats going on in the logic.
We are on the process of migrating everything to Java and this might mean we will have part of our application/softwares/sites running in php and part in Java, due to the volume of the project its very likely to take some time to finish the complete port (php codes are being added all the time also to prototype new features constantly, java is being used to replace and optimize).
Its much easier if the logic is kept independant of any specific language so that whenever a new logic comes in it just gets added to the xml/logic language and either Java or php codes can just read it off from there.
I think it falls in the same category as why we would need XML to represent data when we can use arrays, hashes, databases etc.

 

[timw]

But surely good OO design requires that business logic be encapsulated inside nicely cohesive and decoupled domain classes. If you have it encoded in XML files won't ease of maintenance suffer. And speaking as a coder, I'd rather maintain business logic neatly encapsulated and decoupled inside Java domain classes, than marked-up as XML in a hulking great file. This latter sounds like you're just moving one layer of badly-designed logic into a different place.

 

[sedj]

agreed !

--------------------------------------------------
Free Database Connection Pooling Software

http://www.primrose.org.uk

 

[developerinlondon]

so how would you propose to access it from any other language? and say someone who doesnt know java needs to make changes to the business logic.

 

[timw]

A domain expert specifies the changes needed.
A Java programmer takes the specification and makes the necessary code changes.
If you don't have Java programmers, get some, or do it in the language that you have programmers for.
Don't sacrifice good system design just to allow any old person to be able to make logic changes.

 

[developerinlondon]

i think you are missing the point I am trying to make. I want to have business logic seperated so that it becomes easy as 123 for a child to do if needed. i would find it a waste of resource to always have to need a java programmer to change business logics. its just not the right role.
also the code inside the java domain class is not necessarily the tidiest of codes if you are having many inter-related conditions, exceptions and rules, etc AND you need to go through them each time you make a change and make sure that all inter-related changes dont break up any of the other rules/exceptions/conditions.
i am not necessarily proposing to use xml, but anything a bit more generic and simpler to use then a programming language.
it will be the difference between hardcoding and softcoding the logic. it just does not feel right putting so much coding into a program (java or otherwise) to reflect logic.

think about it for a moment from my point of view. maybe you will see what I am trying to explain

 

[timw]

But if your business logic has lots of necessary inter-relations and conditions, then these are part of your abstract domain, and will therefore NOT go away just because you've managed to move the BL into some generic medium. And if these relationships remain, you'd be better off having experienced developers handling them in a robustly designed framework than letting everybody and anybody at it as you propose.

 

[ca8msm]

i think you are missing the point I am trying to make

On the contrary, I think you are missing the point Tim is trying to make. The general idea of Object Orientated Programming points us towards seperating logic (e.g. a presentation layer, a business layer and a data layer). Although these are seperate layers, they are still defined and written in a programming lanugauge and one is encapsulated by the other.

i would find it a waste of resource to always have to need a java programmer to change business logics

You shouldn't want somebody to be able to make changes to the business logic unless they understand the full implications of the change - i.e. what effects it will have on other parts of the system. If the application is written correctly it will be very easy for the java programmer (or even someone with a small knowledge of java) to make simple changes that shouldn't waste resources. If it does then you have to look at your java programmers to find out why.

I really think that your view of creating a business layer by not using a programming language is ill-founded and you should reconsider this as a viable option.

----------------------------------------------------------------------

Need help finding an answer?

Try the search facilty (

http://www.tek-tips.com/search.cfm)

or read FAQ222-2244 on how to get better results.

 

[ca8msm]

Oh and here's some reading on n-tiered approaches that might point you in the right direction:

http://www.15seconds.com/issue/011023.htm

----------------------------------------------------------------------

Need help finding an answer?

Try the search facilty (

http://www.tek-tips.com/search.cfm)

or read FAQ222-2244 on how to get better results.

 

[timw]

It may also be worthwhile adopting rigorous automated testing.

You obviously experience lots of maintenance problems currently, or you wouldn't have posted the question you did. If you do decide to refactor your business-logic into domain classes in Java, build in automated JUnit tests for all those classes. Do regular builds and run the full automated test suite regularly. If a bug is found in your BL, fix it and enhance the relevant unit test to cover it. Rerun the test suite, which should (if it has good code-coverage) give you some confidence that nothing else was broken by the fix.

Remember, software bugs are a fact of life. 'Free-for-all' access to the logic will allow inexperienced people to change that logic and then bugs will become the whole of your life.

Tim

 

[Diancecht]

Thousands of ideas are cominf to my mind as I read all of this, but let's see if I understood it.

What you want to do is to define a kind of tool that allows some non-experienced programmer or even a non-programmer to develop business logic.

Well, we've done that and the approach we used is to separate development and execution arquitecture. What does it mean?

It means that developers provide business logic part without knowing what's going under it, with a nice user-friendly full-colour zero-code tool..

That logic is translated into xml (could be anything else). The execution architecture just takes those xml and show the presentation layer.

Cheers,

Dian

 

[timw]

Sounds impressive, Dian. Was it much work developing this tool / infrastructure? What were the key technological challenges etc? I'm sure developerinlondon is gonna ask these questions, and I'll admit to being curious.

Tim

 

[developerinlondon]

Yes I think I would be very curious to find out more about your Tools Dian. This may be exactly what I am looking for. Glad to see someone sees my point and had thought of this before! ;-)