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

Groups > comp.lang.java.programmer > #30422 > unrolled thread

MVC Partner

Back to article view | Back to comp.lang.java.programmer

Contents

  MVC Partner Leonan Luppi <leonan.luppi@gmail.com> - 2014-11-26 11:16 -0800
    Re: MVC Partner Arne Vajhøj <arne@vajhoej.dk> - 2014-11-26 14:56 -0500
      Re: MVC Partner Leonan Luppi <leonan.luppi@gmail.com> - 2014-11-26 14:54 -0800
        Re: MVC Partner Arne Vajhøj <arne@vajhoej.dk> - 2014-11-26 18:07 -0500
        Re: MVC Partner Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-26 23:22 +0000
    Re: MVC Partner lipska the kat <lipskathekat@example.com> - 2014-11-26 20:40 +0000
      Re: MVC Partner Leonan Luppi <leonan.luppi@gmail.com> - 2014-11-26 15:01 -0800
        Re: MVC Partner lipska the kat <lipskathekat@example.com> - 2014-11-27 08:56 +0000

#30422 — MVC Partner

Hello Guys,

I have some doubt about MVC. Someone could solve please?

So for my "M" it's need to be my mirror of DB (Entity mapped my JPA for example)?

For my "V" it's need to be interfaces which only show and send to my controller?

For my "C" it's need to be all business rules, calling my DAO to result from DB ?

Someone can give an example please?

[toc] | [next] | [standalone]

#30423

On 11/26/2014 2:16 PM, Leonan Luppi wrote:
> I have some doubt about MVC. Someone could solve please?
>
> So for my "M" it's need to be my mirror of DB (Entity mapped my JPA for example)?
>
> For my "V" it's need to be interfaces which only show and send to my controller?
>
> For my "C" it's need to be all business rules, calling my DAO to result from DB ?
>
> Someone can give an example please?

I would say:

M = interface to business logic
V = display to user
C = handling of user actions

Also see 
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller !

Arne

[toc] | [prev] | [next] | [standalone]

#30425

Em quarta-feira, 26 de novembro de 2014 17h56min41s UTC-2, Arne Vajhøj  escreveu:
> On 11/26/2014 2:16 PM, Leonan Luppi wrote:
> > I have some doubt about MVC. Someone could solve please?
> >
> > So for my "M" it's need to be my mirror of DB (Entity mapped my JPA for example)?
> >
> > For my "V" it's need to be interfaces which only show and send to my controller?
> >
> > For my "C" it's need to be all business rules, calling my DAO to result from DB ?
> >
> > Someone can give an example please?
> 
> I would say:
> 
> M = interface to business logic
> V = display to user
> C = handling of user actions
> 
> Also see 
> http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller !
> 
> Arne

Arne,

Ok, but if 'M' is my business logic. Where can i put my Entity's? 
And the 'V' i understand to display interfaces, but where can i send information to handle on controller? like send my username and password to do logIn.

[toc] | [prev] | [next] | [standalone]

#30427

On 11/26/2014 5:54 PM, Leonan Luppi wrote:
> Em quarta-feira, 26 de novembro de 2014 17h56min41s UTC-2, Arne Vajhøj  escreveu:
>> On 11/26/2014 2:16 PM, Leonan Luppi wrote:
>>> I have some doubt about MVC. Someone could solve please?
>>>
>>> So for my "M" it's need to be my mirror of DB (Entity mapped my JPA for example)?
>>>
>>> For my "V" it's need to be interfaces which only show and send to my controller?
>>>
>>> For my "C" it's need to be all business rules, calling my DAO to result from DB ?
>>>
>>> Someone can give an example please?
>>
>> I would say:
>>
>> M = interface to business logic
>> V = display to user
>> C = handling of user actions
>>
>> Also see
>> http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller !
>
> Ok, but if 'M' is my business logic. Where can i put my Entity's?

Somewhere behind the M.

MVC is not the entire application it is just the front end part.

So:

V
  \
   M with BLL---DAL
  /
C

or:

V
  \
   M with WS Cli---WS Serv/SL---BLL---DAL
  /
C

or whatever suit your needs.

> And the 'V' i understand to display interfaces, but where can i send information to handle on controller? like send my username and password to do logIn.

Traditional web : form submit to C

Swing, JavaFX etc. : events handled by C

Arne

[toc] | [prev] | [next] | [standalone]

#30428

On Wed, 26 Nov 2014 14:54:13 -0800, Leonan Luppi wrote:

> Em quarta-feira, 26 de novembro de 2014 17h56min41s UTC-2, Arne Vajhøj 
> escreveu:
>> On 11/26/2014 2:16 PM, Leonan Luppi wrote:
>> > I have some doubt about MVC. Someone could solve please?
>> >
>> > So for my "M" it's need to be my mirror of DB (Entity mapped my JPA
>> > for example)?
>> >
>> > For my "V" it's need to be interfaces which only show and send to my
>> > controller?
>> >
>> > For my "C" it's need to be all business rules, calling my DAO to
>> > result from DB ?
>> >
>> > Someone can give an example please?
>> 
>> I would say:
>> 
>> M = interface to business logic V = display to user C = handling of
>> user actions
>> 
>> Also see
>> http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller !
>> 
>> Arne
> 
> Arne,
> 
> Ok, but if 'M' is my business logic. Where can i put my Entity's?
>
Everything that isn't GUI-related goes in the Model. 

The Model manages connections to databases, external systems, etc that it 
uses to establish its internal state. When changes are input, the Model 
uses them to update itself and any external data sources that record the 
changes. Similarly, data requests may cause the Model to retrieve data 
from the external sources and trigger a View refresh via the Controller 
so the data gets displayed.  

> And the 'V' i understand to display interfaces,
>
The layout and all code connected with formatting data for display, and 
accepting input from the user (menus, buttons, TestAreas, JTables etc., 
i.e. all the Swing or JavaFX objects go in the View. The only logic it 
contains is for managing the display and passing user input to the Model.

> but where can i send
> information to handle on controller?
>
AFAICT, stuff that the Model needs to know (user inputs that affect its 
state, database query requests, etc can be passed directly to it from the 
View. 

The Controller is triggered by the Model whenever the View should be 
refreshed to display changes in the Model. It is responsible for sending 
all relevant changes to the View, which is then colely responsible for 
presenting them to the user.

> like send my username and password
> to do logIn.
>
The View accepts this input and passes it to the Model, which uses it to 
login to the database and whatever other resources it needs to support 
its internal state. It then sets up its initial state and causes the 
Controller to refresh the View so you see whether the login was 
successful and, if so, shows you the initial Model state.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#30424

On 26/11/14 19:16, Leonan Luppi wrote:
> Hello Guys,
>
> I have some doubt about MVC. Someone could solve please?
>
> So for my "M" it's need to be my mirror of DB (Entity mapped my JPA for example)?
>
> For my "V" it's need to be interfaces which only show and send to my controller?
>
> For my "C" it's need to be all business rules, calling my DAO to result from DB ?
>
> Someone can give an example please?
>

I really think that there is an awful lot of mis-information out there 
about MVC. For example the wikipedia article mentioned by another 
responder talks about MVC being a 'design pattern' when effect it is a 
combination of several design patterns. I think 'paradigm' might be a 
better word.

The *original* idea behind MVC was that you had a Model, this could be 
any persistent store, often but not exclusively a database. The 
Controller was responsible for updating the Model in response to 
interactions with the View. There could be many Views on the Model each 
of which registered themselves with the Controller and each of which 
were updated in response to an interaction with any one of them. so for 
example you could have 3 Views, possibly on 3 different devices and if 
any View was modified by a 'user' the state of the Model was first 
updated by the Controller which then updated *all* the views that were 
registered with it at the time. The finer details escape me, it was some 
years ago when I studied this.

With the advent of Java, Sun came up with something called Model2 IIRC.
In this case you still had your persistent store but the Controller was 
a Servlet (or rather the interface to the Controller was a Servlet) and 
the view was (classically) implemented as a JSP.

The fundamental difference is that because http is a request/response 
protocol and there is no way to 'push' changes initiated by one view to 
other views.

Things may be slightly different now with the advent of asynchronous 
technologies such as Web Sockets.

So, in the classic 3 tier Model 2 web application you have an SQL 
database which would be your Model, a Servlet engine such as Tomcat 
which would host your Servlets (your Controllers) and a (arbitrary) 
client, let's say in this case a web browser, to which you would deliver 
your View implemented as a JSP

Your business logic is typically accessed through a facade accessed by a 
Servlet, your business logic would communicate with a facade onto your 
database, this would initially be an Interface.

The single most important thing to remember is that your business logic 
should be completely decoupled from the View *and* from the Model. In 
this way you can deliver your content to any interface, not just a web 
interface and persist you data to any type of persistence mechanism.


-- 
lipska the kat - treacherous feline.
Proudly nominated for IPOTY 2014 - LIGAF
==================================================
Any GNU/Linux distribution that does not come with
the set of tools required to build its open source
kernel is incomplete. This is an opinion.
==================================================
GNU/Linux user #560883 - linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#30426

Em quarta-feira, 26 de novembro de 2014 18h40min36s UTC-2, lipska the kat  escreveu:
> On 26/11/14 19:16, Leonan Luppi wrote:
> > Hello Guys,
> >
> > I have some doubt about MVC. Someone could solve please?
> >
> > So for my "M" it's need to be my mirror of DB (Entity mapped my JPA for example)?
> >
> > For my "V" it's need to be interfaces which only show and send to my controller?
> >
> > For my "C" it's need to be all business rules, calling my DAO to result from DB ?
> >
> > Someone can give an example please?
> >
> 
> I really think that there is an awful lot of mis-information out there 
> about MVC. For example the wikipedia article mentioned by another 
> responder talks about MVC being a 'design pattern' when effect it is a 
> combination of several design patterns. I think 'paradigm' might be a 
> better word.
> 
> The *original* idea behind MVC was that you had a Model, this could be 
> any persistent store, often but not exclusively a database. The 
> Controller was responsible for updating the Model in response to 
> interactions with the View. There could be many Views on the Model each 
> of which registered themselves with the Controller and each of which 
> were updated in response to an interaction with any one of them. so for 
> example you could have 3 Views, possibly on 3 different devices and if 
> any View was modified by a 'user' the state of the Model was first 
> updated by the Controller which then updated *all* the views that were 
> registered with it at the time. The finer details escape me, it was some 
> years ago when I studied this.
> 
> With the advent of Java, Sun came up with something called Model2 IIRC.
> In this case you still had your persistent store but the Controller was 
> a Servlet (or rather the interface to the Controller was a Servlet) and 
> the view was (classically) implemented as a JSP.
> 
> The fundamental difference is that because http is a request/response 
> protocol and there is no way to 'push' changes initiated by one view to 
> other views.
> 
> Things may be slightly different now with the advent of asynchronous 
> technologies such as Web Sockets.
> 
> So, in the classic 3 tier Model 2 web application you have an SQL 
> database which would be your Model, a Servlet engine such as Tomcat 
> which would host your Servlets (your Controllers) and a (arbitrary) 
> client, let's say in this case a web browser, to which you would deliver 
> your View implemented as a JSP
> 
> Your business logic is typically accessed through a facade accessed by a 
> Servlet, your business logic would communicate with a facade onto your 
> database, this would initially be an Interface.
> 
> The single most important thing to remember is that your business logic 
> should be completely decoupled from the View *and* from the Model. In 
> this way you can deliver your content to any interface, not just a web 
> interface and persist you data to any type of persistence mechanism.
> 
> 
> -- 
> lipska the kat - treacherous feline.
> Proudly nominated for IPOTY 2014 - LIGAF
> ==================================================
> Any GNU/Linux distribution that does not come with
> the set of tools required to build its open source
> kernel is incomplete. This is an opinion.
> ==================================================
> GNU/Linux user #560883 - linuxcounter.net

Thanks lipska. So if I understand, for you the controller must contain the business logic?

[toc] | [prev] | [next] | [standalone]

#30430

On 26/11/14 23:01, Leonan Luppi wrote:
> Em quarta-feira, 26 de novembro de 2014 18h40min36s UTC-2, lipska the kat  escreveu:
>> On 26/11/14 19:16, Leonan Luppi wrote:
>>> Hello Guys,
>>>
>>> I have some doubt about MVC. Someone could solve please?
>>>
>>> So for my "M" it's need to be my mirror of DB (Entity mapped my JPA for example)?
>>>
>>> For my "V" it's need to be interfaces which only show and send to my controller?
>>>
>>> For my "C" it's need to be all business rules, calling my DAO to result from DB ?
>>>
>>> Someone can give an example please?
>>>
>>
>> I really think that there is an awful lot of mis-information out there
>> about MVC. For example the wikipedia article mentioned by another
>> responder talks about MVC being a 'design pattern' when effect it is a
>> combination of several design patterns. I think 'paradigm' might be a
>> better word.
>>
>> The *original* idea behind MVC was that you had a Model, this could be
>> any persistent store, often but not exclusively a database. The
>> Controller was responsible for updating the Model in response to
>> interactions with the View. There could be many Views on the Model each
>> of which registered themselves with the Controller and each of which
>> were updated in response to an interaction with any one of them. so for
>> example you could have 3 Views, possibly on 3 different devices and if
>> any View was modified by a 'user' the state of the Model was first
>> updated by the Controller which then updated *all* the views that were
>> registered with it at the time. The finer details escape me, it was some
>> years ago when I studied this.
>>
>> With the advent of Java, Sun came up with something called Model2 IIRC.
>> In this case you still had your persistent store but the Controller was
>> a Servlet (or rather the interface to the Controller was a Servlet) and
>> the view was (classically) implemented as a JSP.
>>
>> The fundamental difference is that because http is a request/response
>> protocol and there is no way to 'push' changes initiated by one view to
>> other views.
>>
>> Things may be slightly different now with the advent of asynchronous
>> technologies such as Web Sockets.
>>
>> So, in the classic 3 tier Model 2 web application you have an SQL
>> database which would be your Model, a Servlet engine such as Tomcat
>> which would host your Servlets (your Controllers) and a (arbitrary)
>> client, let's say in this case a web browser, to which you would deliver
>> your View implemented as a JSP
>>
>> Your business logic is typically accessed through a facade accessed by a
>> Servlet, your business logic would communicate with a facade onto your
>> database, this would initially be an Interface.
>>
>> The single most important thing to remember is that your business logic
>> should be completely decoupled from the View *and* from the Model. In
>> this way you can deliver your content to any interface, not just a web
>> interface and persist you data to any type of persistence mechanism.
>>
>>
>> --
>> lipska the kat - treacherous feline.
>> Proudly nominated for IPOTY 2014 - LIGAF
>> ==================================================
>> Any GNU/Linux distribution that does not come with
>> the set of tools required to build its open source
>> kernel is incomplete. This is an opinion.
>> ==================================================
>> GNU/Linux user #560883 - linuxcounter.net
>
> Thanks lipska. So if I understand, for you the controller must contain the business logic?
>

Probably better to say the controller has access to the business logic 
via a facade which aggregates fine(er) grained business logic methods 
and presents them as atomic methods to the controller (Servlet in the 
case of Model 2).

Whatever methods you use:

Saying that the controller 'contains' the business logic implies (to me 
at least) that the business logic 'depends' on the controller which is 
'not a good idea' Your business logic should exist almost as a separate 
entity this way it can be reused to deliver a service regardless of 
pattern/paradigm/interface etc

I'd say it was like Aggregation versus Composition, your controller 
should have an aggregate relationship with your business logic rather 
than a composite one.

I have to confess most of my experience is with 'Model 2' and I have a 
'methodology' if you want to call it that that has worked well for 
several years and many different applications.

*Real* MVC is somewhat different as explained by others of course, even 
so, I think that if you decouple your business logic as far as you can 
then theoretically you should be able to (re)use it regardless of which 
'incantation' of MVC you use.

This is just my opinion of course.


-- 
lipska the kat - treacherous feline.
Proudly nominated for IPOTY 2014 - LIGAF
==================================================
Any GNU/Linux distribution that does not come with
the set of tools required to build its open source
kernel is incomplete. This is an opinion.
==================================================
GNU/Linux user #560883 - linuxcounter.net

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web