Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #6158

Re: Support for both Web and Desktop front-ends [Architecture]

Show key headers only | View raw

On 11-07-13 12:41 AM, Warren Tang wrote:
> I'm about to develop an application which needs to support both Web
> client and desktop client. Is there any existing tools/practices I can
> use? Or any suggestions?
> 
> Recently I've done a project with Google Web Toolkit(GWT) + myBatis.
> Newly shifted from .NET Framework to Java, my current knowledge set is
> limited to core java, no Java EE or Spring experience (though I have
> plans to learn them).So lightweight is preferred.
> 
> Maybe I can use GWT + Spring + myBatis? For the desktop front-end I
> should use Swing + Spring + MyBatis? The Spring MVC can handle the two
> front-ends and make sharing business logic easier?
> 
A few points. First, don't scramble this question up with persistence.
Whatever you end up using - straight JDBC, JPA with Hibernate or
EclipseLink, or the MyBatis framework - is irrelevant at the moment.

Two: do you know why you want to use Spring? Quite frankly, before
Spring got all bloated up, which is roughly coeval with the period when
use of Java SE/EE could somewhat benefit from Spring (prior to JDK 1.5
and Jave EE 5, basically), there was a reasonably good argument for
Spring. That core argument, with recent/latest Java SE/EE, has
evaporated. Learn Spring if you must, but as a Java novice (and Java EE
total tyro) do it in isolation on some other project for the sole
purpose of learning Spring: don't mix it up with other decisions or make
the use of Spring - to you an unknown puzzle - part of this decision.

I'll also add that you said you preferred "lightweight". It's a cruel
joke that Spring people still bandy that word around. Believe you me,
nothing but nothing - not library load, not design complexity, not
coding complexity - is "lightweight" about Spring. Not anymore. That
team lost their way many years ago.

Fundamentally, though, learn about Spring, when you have time, in
relative isolation. You'll end up pretty frustrated if you try to do
desktop+web+Spring+persistence all at once.

To address the basic concern, sharing of business logic, let me first
establish one common language by introducing a 4-layer architecture:
Presentation/UI layer, Application/Services layer, Domain/Model/Business
layer, and Infrastructure (technical services like data access and
logging) layer.

We assume, and should strive for, the same Domain layer and the same
Infrastructure layer for both of your scenarios. Those layers shouldn't
care one whit what the clients are, whether web or desktop front-end.

Having said that, your use cases tell you what your
domain/infrastructure layers need to do, without reference to client type.

Your web presentation layer will be GWT or Spring MVC or JSF or Wicket,
for example. Myself I'd go with JSF 2.x, but I won't discount the
others. In particular note that my concerns wrt Spring are towards the
entire Spring framework, not Spring MVC in isolation. If you want to go
with GWT I won't tell you not to. I will however recommend at least
looking at JSF 2.x.

To clarify the purpose of the Application/Services layer in the 4-layer
architecture, keep in mind what the Domain and Infrastructure layers are
doing for you, and also consider that the Presentation layer (Swing and
web-something, say) is solely concerned with presenting. The glue
between Presentation and Domain is Application - this is conceptually
where your "controller" type logic goes. For example, state that
reflects user progress in completing a task is the responsibility of the
Application layer, and so is logic that identifies and invokes domain
logic in response to events like user gestures and input. This layer
will not be the same for all clients, because the HTTP
request-response/requestScope-sessionScope breaks up your workflow
differently than a desktop does.

In other words:

1. Proper design from good use cases will give you business and
persistence logic that can be shared by all clients (throw WS endpoints
and WS clients in a SOA architecture into the mix, and divide web
clients into desktop browsers and mobile browsers...it still doesn't
affect the domain and infrastructure layers);

2. For each client the presentation layer is independently developed
(GWT, Swing etc). No sharing is contemplated. Stuff in this layer,
because it's inherently concerned with UI only, is also quite modular;

3. The application/services layer is also client-specific (although
you'd have some sharing for browser clients of various types).
Understand this layer, and get it right, because a developed knack for
identifying what belongs in this "controller" layer is a valuable skill
for your scenario. Bear in mind that in a web app this layer will
probably live in the web tier: just keep the distinction between the 2
layers in the web tier in mind.

Since you've arrived from a .NET world none of this should be all that
new. You are basically identifying the business and infrastructure logic
that would be in the Model either in ASP.NET MVC or WPF
Model-View-ViewModel (MVVM), the application/services layer that
translates to either the Controller in ASP.NET MVC or the ViewModel (or
ViewModel+Controller) in MVVM, and the presentation/UI layer that
translates to the View in both ASP.NET MVC and WPF MVVM. You already
know how you can write common C# library code for business logic and
persistence that will work both in a WPF or WinForms or ASP.NET MVC app;
keep in mind that anything that would inevitably be different between
those client environments is actually application/services layer or
presentation layer code.

So this reply is really an overview of architectural practices with a
view to telling you that whatever you did right in the .NET world
carries over precisely into the Java world.

As a completely personal choice, I'd  use Swing for the desktop
presentation layer, and JSF 2.x for the browser client. There are some
situations where I'd use straight JDBC or MyBatis-managed SQL, but I
suggest that you won't step wrong by considering JPA, which would be my
usual choice for persistence.

I would not use Spring in general. I do not tell you not to learn it,
because there are plenty of dev shops out there that are wedded to it,
and for purely professional reasons it doesn't hurt to be fairly capable
with it. I didn't much like CORBA either, but I knew how to use it.

AHS

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Support for both Web and Desktop front-ends [Architecture] Warren Tang <nospam@tangcs.com> - 2011-07-13 11:41 +0800
  Re: Support for both Web and Desktop front-ends [Architecture] markspace <-@.> - 2011-07-12 21:21 -0700
    Re: Support for both Web and Desktop front-ends [Architecture] Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:53 -0400
      separated by a common language "Richard Maher" <maher_rj@hotspamnotmail.com> - 2011-07-24 08:13 +0800
        Re: separated by a common language Arne Vajhøj <arne@vajhoej.dk> - 2011-07-23 21:37 -0400
  Re: Support for both Web and Desktop front-ends [Architecture] Tom <tom400f@gmail.com> - 2011-07-13 10:34 +0000
    Re: Support for both Web and Desktop front-ends [Architecture] Tom <tom400f@gmail.com> - 2011-07-13 12:28 +0000
  Re: Support for both Web and Desktop front-ends [Architecture] Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-07-13 07:36 -0300
  Re: Support for both Web and Desktop front-ends [Architecture] jebblue <n@n.nnn> - 2011-07-13 22:17 -0500
  Re: Support for both Web and Desktop front-ends [Architecture] Roedy Green <see_website@mindprod.com.invalid> - 2011-07-13 21:22 -0700
    Re: Support for both Web and Desktop front-ends [Architecture] Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:45 -0400
  Re: Support for both Web and Desktop front-ends [Architecture] Kristian Rink <kr@zimmer428.net> - 2011-07-14 13:06 +0200
  Re: Support for both Web and Desktop front-ends [Architecture] Arne Vajhøj <arne@vajhoej.dk> - 2011-07-21 18:33 -0400

csiph-web