Separating UI logic & program logic

[Moiv]

What is the most common approach(es) to separating the user interface
programming from the program itself?

Basically I want to write a simple MP3 player like winamp, initially I will
be using a winform to control the program and later down the track I might
change it to a WPF user interface.

I'm thinking perhaps the program itself could be built into a DLL and the
user interface uses that DLL and creates an instance of the "program"
object?
The interface can then control the program object via its methods etc.
Then events in the program to trigger actions which the user interface
reacts to?

I'm coming from a PHP and BASIC background, so everything in C#.net seems to
be the reverse of what I'm used to.

Thanks for any advice

 

[Moiv]

"Peter Duniho" wrote in message

[...]
"I know you are but what am I" is not a debate style that will earn
you respect, it only works for Pee Wee Herman in movies.

I am not concerned with winning respect. I simply care about the truth.
The truth in this matter is that your very complaints are most
appropriate only redirected at yourself. You are the one claiming
absolutes, not I.

I did that in my first message. Suppose you learn to read?

You did nothing of the sort, not the first time nor the second, and ad
hominem will get you nowhere.

 

[Arne Vajhøj]

[...]

It is not really necessary to separate the non-UI logic from the UI
logic by putting it into a separate DLL, but you can of course do that
if you want.

Its not necessary if you want to end up with a bad design, but for the
functionality described here, it would be a very bad idea not to.

That's absurd. It is patently false that there is any problem whatsoever
in putting all the code into a single assembly, never mind that it would
be "a very bad idea".

It is a bad idea.

Putting it in a single assembly make it the responsibility of the
programmer to keep the separation.

By putting it in multiple assembly it is possible to use the
features of C#/.NET to enforce the separation.

[...]
A well written set of program logic should be be able to have a
Winforms front end, or a WPF front end, or a web front end, or called
from web services to provide the functionality to an iPhone or
whatever UI requirement is applicable to that particular type of
program (you can already see how a typical MP3 player might not be the
best example, but its better to implement good practices in every type
of project).

That's all well and good. But…

This means for good it is an absolute requirement to
put, and keep, all of this sort of business logic in its own assembly.
[...]

It doesn't mean that at all.

The app can be made to work without being split, so it is not an
absolute requirement.

But it is bad idea not to do the split.

Arne

 

[Arne Vajhøj]

Suppose YOU explain why EVERY program MUST be written so as to
anticipate the reuse of the non-UI logic in multiple settings,

It is a key aspect of most OOP and CBD best practices that you may
never need the functionality, but on the other hand you may end up
needing it. Those that believe they can foresee the future then
code based on their vision. Those with the engineering approach
realize that they don't know where it will be needed and where
it will not be needed, so they do it the right way every time
to cover all cases.

never
mind why such an anticipation _requires_ that the code be placed in
separate assemblies.

That should be obvious for anyone understanding C# and .NET!

In programming, as with most of the rest of the real world, there is
very little that is "absolute".

There is a lot in programming about best practices.

I can give you a few references if you doubt it.

Arne

 

[Marcel Müller]

Putting it in a single assembly make it the responsibility of the
programmer to keep the separation.

By putting it in multiple assembly it is possible to use the
features of C#/.NET to enforce the separation.

The language will detect if the logic needs the UI, because the
UI-assembly must not be in the reference list of the logic. But the
other way around (putting logic in the UI) is in fact still up to the
programmers discipline.
I rarely found the first anti pattern, but I frequently see the latter.
So the benefit is limited. Only the psychological barrier when creating
a logic class in the GUI assembly might help.


Marcel

 

[Arne Vajhøj]

[...]

In programming, as with most of the rest of the real world, there is
very little that is "absolute".

There is a lot in programming about best practices.

And very little of that is "absolute".

It is always absolute. Otherwise it would be called "some practice".

It is sometimes conditional though.

I am not even going to waste my time on this TWO MONTH OLD conversation.

Well AFAIK then best practice regarding separation between layers
has not changed since then.

If you have changed you point of view since then just say so.

You should have read what I wrote more carefully, as nothing in your
reply actually addresses my point, never mind refutes it.

It actually addresses all of it.

The fact that you as usual tried to camouflage it by snipping away
the relevant stuff do not change that.

If you're going to be a Johnny-come-lately, at least do a proper job of
catching up on what's been written already before sticking your own two
cents in.

I read it.

And was horrified that anyone in 2011 could suggest what you did.

Arne

 

[Registered User]

[...]
It is not really necessary to separate the non-UI logic from the UI
logic by putting it into a separate DLL, but you can of course do that
if you want.

Its not necessary if you want to end up with a bad design, but for the
functionality described here, it would be a very bad idea not to.

That's absurd. It is patently false that there is any problem whatsoever
in putting all the code into a single assembly, never mind that it would
be "a very bad idea".

It is a bad idea.

Bad idea or not, having 'everything' in a single assembly will always
raise questions about the solution's design. Highest level
abstractions outline the separation of concerns.The design should
follow these logical inferences and make use of multiple assemblies.

The subject line of this thread is the highest level of abstraction
and indicates the solution should contain at least two assemblies.

Putting it in a single assembly make it the responsibility of the
programmer to keep the separation.

If the programmer has to maintain high level abstractions within a
project something is terribly wrong with the design. The programmer's
focus should be on detailing lower level abstractions. The high level
details should be already be abstracted away.

By putting it in multiple assembly it is possible to use the
features of C#/.NET to enforce the separation.

This is what it's all about. A proper design leverages the tools to
advantage and simplifies the implementation of lower level
abstractions.

[...]
A well written set of program logic should be be able to have a
Winforms front end, or a WPF front end, or a web front end, or called
from web services to provide the functionality to an iPhone or
whatever UI requirement is applicable to that particular type of
program (you can already see how a typical MP3 player might not be the
best example, but its better to implement good practices in every type
of project).

That's all well and good. But…

This means for good it is an absolute requirement to
put, and keep, all of this sort of business logic in its own assembly.
[...]

It doesn't mean that at all.

The app can be made to work without being split, so it is not an
absolute requirement.

Much depends upon what 'work' means. Expedient solutions which give
design short shrift tend to use looser definitions and fewer metrics.
They may work to a fashion but reusability and maintainability are
never considered in the design.

But it is bad idea not to do the split.

It should be an absolute design requirement to avoid the use of
anti-patterns. Putting a UX and BL in the same assembly abstractly
represents the Smart UI anti-pattern regardless of the internal
separation.

regards
A.G.

 

[Arne Vajhøj]

The language will detect if the logic needs the UI, because the
UI-assembly must not be in the reference list of the logic.

That is one of the reasons but not the only for separating.

But the
other way around (putting logic in the UI) is in fact still up to the
programmers discipline.

Putting new logic in the UI is difficult to prevent, but misusing
the existing logic is another thing that separating help with.

I rarely found the first anti pattern, but I frequently see the latter.

I agree.

So the benefit is limited.

No, separating also help prevent the second.

Arne

 

[Arne Vajhøj]

On 6/18/11 7:46 PM, Larry P. wrote:
[...]
A well written set of program logic should be be able to have a
Winforms front end, or a WPF front end, or a web front end, or called
from web services to provide the functionality to an iPhone or
whatever UI requirement is applicable to that particular type of
program (you can already see how a typical MP3 player might not be the
best example, but its better to implement good practices in every type
of project).

That's all well and good. But…

This means for good it is an absolute requirement to
put, and keep, all of this sort of business logic in its own assembly.
[...]

It doesn't mean that at all.

The app can be made to work without being split, so it is not an
absolute requirement.

Much depends upon what 'work' means. Expedient solutions which give
design short shrift tend to use looser definitions and fewer metrics.
They may work to a fashion but reusability and maintainability are
never considered in the design.

But it is bad idea not to do the split.

It should be an absolute design requirement to avoid the use of
anti-patterns. Putting a UX and BL in the same assembly abstractly
represents the Smart UI anti-pattern regardless of the internal
separation.

I do not disagree with your point if view.

I just prefer to use terms like "best practice", "good OOP",
"good CBD" etc. and reserve "requirement" to more traditional
functional and non-functional such.

Arne

 

[Arne Vajhøj]

[...]
Well AFAIK then best practice regarding separation between layers
has not changed since then.

Yes, you always use that as your defense when you come back two months
later and litter the newsgroup with resurrected threads.

_Maybe_ if you were actually reading the threads before you replied to
them, in _some_ cases there might be a point to adding to the
conversation. But that's not what you're doing. You're just inventing
straw men and knocking them down.

I think I quoted you accurately and commented on what you wrote.

That is not inventing straw men.

Arne