I'm trying to do a three-layer server-client:
1st layer: send data to 2nd layer
2nd layer: receive data from 1st and send it to 3rd
3rd layer: receive data from 2nd layer
By this way, 2nd layer need to be implemented as both server and client, is that doable with twisted ?
This might be something close to what you're looking for. Or at least, it could probably implement layer 2 in your scheme. The 1st and 3rd layers would just be normal ServerProtocol/ClientProtocol. The middle has to essentially be a proxy between the two. As you can see in the example, an approach to this is attaching a clientfactory to the serverprotocol.
Related
MVC in the frontend makes perfect sense. But why do we need MVC in the backend as well? Where is the "view" in this case given backend doesn't provide anything visual.
MVC is a design pattern that promotes separation of concern where three participating concerns are
•
The Model a data structure which holds business data and is
transferred from one layer to the other.
The View which is responsible to show the data present in the
application or think of it as a data structure (complete decoupled
from the model) solely used for presentation purpose (not necessary a
presentation output itself) e.g. view template in below diagram
The Controller act as a mediator and is responsible to accept a
request from a user, modify a model (if required) and convert it into
the view.
MVC as a pattern can exist completely on the backend or completely on frontend or in its common form of backend and frontend combined.
One has to think relatively and see how to keep all these three concerns sperate for better application design.
The whole idea behind MVC pattern is a very clear separation between domain objects which represents real-world entities and the presentation layer data structure. Domain objects should be completely independent and should work without a View (data representation) as well. Or other way to think of it is, in MVC context views are isolated from the model. It allows to use the same model with different views.
Spring MVC is a good example of a backend MVC framework.
Below diagram depicts how all the three components exist on the server side only (inside the application container). Taken from official blog only.
MVC is about separating concerns in applications that accept user input, perform business logic, and render output. It does not say where that logic resides. Nor does it specify that all the logic must live in a single process.
A fairly traditional use of MVC is with a spreadsheet. Let's look at both a single process application and a multi-process application to see how they might implement this simple spreadsheet:
A B C
----- ----- ---------
1 | 1 2 =A1+B1
Let's say the user enters the number 4 into cell A1. What happens?
SINGLE PROCESS APPLICATION (e.g. Microsoft Excel): The user input is handled by the view logic, up until the user leaves the cell. Once that happens, the controller receives a message to update the model with the new value. The model accepts the new value, but also runs some business logic to update the values of other cells affected by the change. Once complete, the model notifies the view that its state has changed, and the view renders the new state. That notification can happen via pub/sub as #jaco0646 suggests, but it could also be handled with a callback.
MULTI-PROCESS APPLICATION (e.g. Google Sheets): The user input is handled by the view logic (in the client), up until the user leaves the cell. Once that happens, the controller (on the server) receives a message (via HTTP, or a socket) to update the model (also on the server) with the new value. The model accepts the new value, but also runs some business logic to update the values of other cells affected by the change. Once complete, the model notifies the view that its state has changed, and the view renders the new state (in the client). That notification can happen via the controller's HTTP response, or via a socket.
In other words, the MVC pattern is applicable to both scenarios.
Furthermore, it is also perfectly valid to treat the client and the server as two entirely separate applications, both of which might implement MVC. In this scenario, both the client's model, and the server's view are less traditional. The client's model is likely making AJAX requests to the server, as opposed to running complex business logic itself or persisting the data locally. And, the server's view is likely a serializer that produces some form of structured output that the client understands, like JSON, XML, or even a CSV.
MVC is a perfectly valid pattern anytime an application needs to accept user input, perform some business logic, and render some output -- regardless of whether that application lives on one or more processes -- and regardless of whether the view is something a human will consume.
I am using websocket based MVC architecture, This MVC life cycle is similar to Spring and Struts, now I have to support periodic update for my views.
Each controller is responsible for each view present in the client
Controller has to update the view in a periodic interval
I am not maintain any session for each client. So the controller has to update for all clients.
I dont want to create thread inside Controller, because we have so many controllers for each view.
So, I want to create a separate module that has to handle this periodic update via Controller (by calling Controller methods).
At last, I want to keep the client just for display, so I dont want to keep timer in client side.
I want to follow some standard way to design this, please help me to follow the standard design patterns (like MVC) to do this.
Two cents of a spring, struts programmer for a websocket programmer.
1.Each controller is responsible for each view present in the client
[Good design, Hope you are not over engineering]
Point 2 and point 3.
Approach 1 - Since there is no session ask your UI/View to send a request to controller for update after a specific interval (say 2 mins) or after a specific event (say page refresh/reload) which ever suits your requirement.
Cons of the approach - Too many frequent updates by the UI/View side code can bring your application on its knees as client code can be changed and use to attack the application.
To avoid this you will need to take care in each request is authentic and complete in itself and can be executed independently.
Pros of the approach - Consider scaling an application, it can scale like anything.
Point 4 and 5 they are similar
controller {
doSomething(){};
}
Or
controller {
HelperCalssReference.doSomething(){};
}
you will always get a thread inside controller [in terms of execution speed] but second approach is more decoupled.
Point 6 and Point 3.
"No timer on the client side" well then maintain session on the server side
but "I am not maintain any session for each client" you have to keep it somewhere take a pick.
Don't maintain a session on server but have to keep track of the clients and send them new update say after 2 mins but how you will know when to stop or the client is offline if you want to stop say after 5 updates from the server you are good but your client UI may be online and waiting for updates.
Point is have a logical break point in your program but can't find that in above requirements.
Probable Approaches -
Use REST keeps an application scale-able and stateless.
[https://capgemini.github.io/architecture/is-rest-best-microservices/ must read section "Design / Implementation/ Configuration Difficulty"]
Use Hollywood design principle but decide who is your Hollywood UI/view or the server.
Event driven approach can help let the user event decide when to ask for update
[watch out for client asking for 3 updates in 1 second by multiple clicks.]
Happy designing :)
I want to try to write (amateur here!) a multiplayer game, and now at designing I decided to use the MVC-pattern.
Now my question is: where should I put my networking code? In the Model or the Controller? (Obviously not the View)
EDIT:
Sorry, for the hundredst time my question was unclear.
The game itself will be MVC, and it will firstly communicate with a server (find player), and later with that player (send your turn and get other's turn). So where should I do that?
The MVC design pattern is actually a combination of two layers: presentation layer and model layer. Presentation layer usually deals with user interface (updates it and reacts to user's interaction). The model layer deals with domain business logic and persistence.
The networking code should go in the model layer.
To be exact, in the part of model layer, that deals with persistence, because there, from the standpoint of business logic, there is no difference where the data comes from. It can be from the SQL database, from opened network socket or detector on the mars rover. Those all are just data sources, which, often implemented as data mappers, are part of the model layer.
You could put the actual game itself in a new project and reference that between your MVC application, that way your game is entirely separated from your web application. This could be useful if you ever wanted to port it to WPF for instance. Another alternative is to have the game as Web Service which the MVC application requests information from and would provide scalability for additional languages to plugin in.
However, if you decide to keep everything as a whole in MVC then I would suggest the Model.
As a breakdown:
The controller takes care of all the web requests, i.e. GET and POST. It can also populate a model and return the appropriate view for that request.
The model contains the domain objects and logic to perform (i.e. extracting information from the repository and manipulating the data to be passed to the view).
The view returns the markup which is based upon the data stored within the model.
In certain implementations additional logic such as checking conditions and Repository calls also take place at the controller level, which is a technique known as Fat Controller Thin Model.
Edit:
You should be sending a request to the controller. I.e. In your games controller have a HTTPPost method that connects to the server and then sends the players turn info and gets the new information. For example:
[HttpPost]
public ActionResult SendPlayerTurnInformation(PlayerObject player)
{
// logic to connect to the Game Network
// connection.UpdatePlayerTurn(player);
//return success/fail
}
You could then do the same to get a specific players turn information and then update your model to be passed to the view which would contain the new information.
1) What are the BLL-services? What's the difference between them and Service Layer services? What goes to domain services and what goes to service layer?
2) Howcome I refactor BBL model to give it a behavior: Post entity holds a collection of feedbacks which already makes it possible to add another Feedback thru feedbacks.Add(feedback). Obviosly there are no calculations in a plain blog application. Should I define a method to add a Feedback inside Post entity? Or should that behavior be mantained by a corresponing service?
3) Should I use Unit-Of-Work (and UnitOfWork-Repositories) pattern like it's described in http://www.amazon.com/Professional-ASP-NET-Design-Patterns-Millett/dp/0470292784 or it would be enough to use NHibernate ISession?
1) Business Layer and Service Layer are actually synonyms. The 'official' DDD term is an Application Layer.
The role of an Application Layer is to coordinate work between Domain Services and the Domain Model. This could mean for example that an Application function first loads an entity trough a Repository and then calls a method on the entity that will do the actual work.
2) Sometimes when your application is mostly data-driven, building a full featured Domain Model can seem like overkill. However, in my opinion, when you get used to a Domain Model it's the only way you want to go.
In the Post and Feedback case, you want an AddFeedback(Feedback) method from the beginning because it leads to less coupling (you don't have to know if the FeedBack items are stored in a List or in a Hashtable for example) and it will offer you a nice extension point. What if you ever want to add a check that no more then 10 Feedback items are allowed. If you have an AddFeedback method, you can easily add the check in one single point.
3) The UnitOfWork and Repository pattern are a fundamental part of DDD. I'm no NHibernate expert but it's always a good idea to hide infrastructure specific details behind an interface. This will reduce coupling and improves testability.
I suggest you first read the DDD book or its short version to get a basic comprehension of the building blocks of DDD. There's no such thing as a BLL-Service or a Service layer Service. In DDD you've got
the Domain layer (the heart of your software where the domain objects reside)
the Application layer (orchestrates your application)
the Infrastructure layer (for persistence, message sending...)
the Presentation layer.
There can be Services in all these layers. A Service is just there to provide behaviour to a number of other objects, it has no state. For instance, a Domain layer Service is where you'd put cohesive business behaviour that does not belong in any particular domain entity and/or is required by many other objects. The inputs and ouputs of the operations it provides would typically be domain objects.
Anyway, whenever an operation seems to fit perfectly into an entity from a domain perspective (such as adding feedback to a post, which translates into Post.AddFeedback() or Post.Feedbacks.Add()), I always go for that rather than adding a Service that would only scatter the behaviour in different places and gradually lead to an anemic domain model. There can be exceptions, like when adding feedback to a post requires making connections between many different objects, but that is obviously not the case here.
You don't need a unit-of-work pattern on top on the NHibernate session:
Why would I use the Unit of Work pattern on top of an NHibernate session?
Using Unit of Work design pattern / NHibernate Sessions in an MVVM WPF
I was wondering what exactly is the difference between MVC(which is an architectural pattern) and an n-tier architecture for an application. I searched for it but couldn't find a simple explanation. May be I am a bit naive on MVC concepts, so if anyone can explain the difference then it would be great.
N-tier architecture usually has each layer separated by the network. I.E. the presentation layer is on some web servers, then that talks to backend app servers over the network for business logic, then that talks to a database server, again over the network, and maybe the app server also calls out to some remote services (say Authorize.net for payment processing).
MVC is a programming design pattern where different portions of code are responsible for representing the Model, View, and controller in some application. These two things are related because, for instance the Model layer may have an internal implementation that calls a database for storing and retrieving data. The controller may reside on the webserver, and remotely call appservers to retrieve data. MVC abstracts away the details of how the architecture of an app is implemented.
N-tier just refers to the physical structure of an implementation. These two are sometimes confused because an MVC design is often implemented using an N-tier architecture.
If a 3-tier design were like this:
Client <-> Middle <-> Data
the MVC patter would be:
Middle
^ |
| v
Client <- Data
Meaning that:
in the 3-tier equivalent, communication between layers is bi-directional and always passes through the Middle tier
in the MVC equivalent the communication is in unidirectional; we could say that each "layer" is updated by the one at the left and, in turn, updates the one at the right –where "left" and "right" are merely illustrative
P.S. Client would be the View and Middle the Controller
This is what say about n-tier architecture
At first glance, the three tiers may
seem similar to the MVC (Model View
Controller) concept; however,
topologically they are different. A
fundamental rule in a three-tier
architecture is the client tier never
communicates directly with the data
tier; in a three-tier model all
communication must pass through the
middleware tier. Conceptually the
three-tier architecture is linear.
However, the MVC architecture is
triangular: the View sends updates to
the Controller, the Controller updates
the Model, and the View gets updated
directly from the Model.
The only similarity is that the two patterns have three boxes in their diagrams. Fundamentally they are completely different in their uses. If fact, it is not usually a choice between which pattern to use, but both patterns can be use together harmoniously. Here is a good comparison of the two: http://allthingscs.blogspot.com/2011/03/mvc-vs-3-tier-pattern.html
This diagram shows how both patterns can be used together, with MVC used solely within the Presentation/UI Tier:
Give yourself a break. And don't restrict yourself to certain patterns when solving real-world problems. Just remember some general principles, one of which is SEPARATION OF CONCERNS.
A fundamental rule in three-tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middleware tier.
It’s liner architecture. This addresses the question of how to pass information between a user and a database. Where as MVC is a triangular architecture: the View sends updates to the Controller, the Controller updates the Model, and the View gets updated directly from the Model. This addresses questions of how a user interface manages the components on the screen.
#Cherry
Middle ware works more like a request handler or redirector in MVC Pattern.
I would like to explain a bit about MVC, According to me Model View Controller works like this.
Client initiates the session by requesting for any service.
This request is received and handled by Controller (Request handler, redirector etc)
Controller process a basic info on the request and redirect it to the relevant Model which can fill up the data request.
Model fill up the request according to the parameters passed by Controller and send back the results to Controller. (Note: Here i like to clear that data is not directly returned to client in true MVC architecture, rather it fills up and returned to controller.)
Controller than send that data to View(Client).
Client has the requested service in front of him.
That's all about MVC that i know.
An N-Tier architecture is best defined using a Deployment Diagram.
An MVC architecture is best defined using a Sequence Diagram.
The 2 are not the same and are not related and you can combine the two architectures together. A lot of companies have taken the steps to create N Tier'd architecture for not only deployment and scalability, but for code reuse as well.
For example, your Business Entity objects may need to be consumed by a desktop app, a web service exposed for a client, a web app, or a mobile app. Simply using an MVC approach will not help you reuse anything at all.
Besides being linear, another major difference that was not emphasized enough here is that in the N-tier model, N is not necessarily 3-tiers! It is most often implemented as three tiers (presentation, app, data) with the middle layer having two sub-tiers (business logic and data access). Also, the model in MVC can contain both data and business logic for data manipulation, whereas these would be in separate tiers in n-tier.
Conclusion : N-tier is an architecture, MVC a design pattern. They are the same metaphore applied in two different fields.
Jerry: Here's a simple example of how the two are related:
Tier 1 - Consists of Models that communicate with Tier 2 through some sort of network service or similar, controllers to handle input validation, calculations and other things relevant for the views. And it contains the views themselves, ofcourse - which can be the GUI in a desktop-app, or the web-interface in a web-app.
Tier 2 - Contains some sort of service or other way of recieving messages from Tier 1. Does not/should not know about Tier 1, so can only answer to calls from above - never ask for things by itself. Also contains all business-logic.
Tier 3 - Contains the domain model, object representation of the database and all logic to communicate and update database-entries.
N-tier architecture never communicates directly to the data access layer. In a 3-tier architecture:
Presentation layer presents the related UI,
Business layer contains related logic and
then the data access layer.
All the data communicates through the middle tier. Presentation <-> Business <-> Data.
MVC (Model-View-Controller) architecture is triangular.
The View sends updates to the controller,
The Controller updates the Model and
then the View directly gets updates from the model.
Model(Data), View(UI), Controller(Logic).