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

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

Re: MVC Partner

Show all headers | View raw

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

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

Thread

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

csiph-web