Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
So usually when working with the MVC you have a controller that controls the input a model that process it and makes it ready for the user and a view that display the "result" to the user.
Now when creating this pattern you seperate the code into their relevant place. for instance the controller code goes into the controller, the gui code goes into the view and so on.
Now my question is if we look at all of the design patterns out there for instance the observer pattern. How would you apply such pattern to a code structure that already implements the MVC pattern? for that case many of the other patterns aswell such as composite, factory and command pattern?
Doesnt the structure of the MVC pattern make it harder to implement other good pratice design patterns?
MVC is not a Design Pattern, it's an Architecteral Pattern.
Wikipedia :
An architectural pattern is a standard design in the field of software architecture. The concept of an architectural pattern has a broader scope than the concept of design pattern. The architectural patterns address various issues in software engineering, such as computer hardware performance limitations, high availability and minimization of a business risk. Some architectural patterns have been implemented within software frameworks.
So it's not fair to compare MVC with design patterns. Design patterns can be implemented on each of these logical modules (Model, View and Controller)
You can have other patterns in your views. For example, you could use the mediator pattern to communicate between modules or views in your javascript. You could also use the observer pattern, too.
Here is a video of a presentation given by Nicholas Zakas on how to use the sandbox pattern. It is very similar to the mediator pattern, but it is a little more complex and it allows you to create modules that are even more loosely coupled. http://www.youtube.com/watch?v=7BGvy-S-Iag
This can be implemented in javascript while still using the mvc pattern. For example, you could use this with Rails, which naturally forces mvc by convention.
Edit: Technically, Rails is not MVC, but you get the idea. More information on that here: What is MVC in Ruby on Rails?
MVC is an architectural pattern. Like all architectural patterns it is made up of several design patterns.
The relationship between views and models is the Observer Pattern. Controllers are interchangeable strategies of the views. And the views are using the Composite Pattern.
Those are only the core patterns of MVC. The model is often a Mediator and the Views may contain Decoratoras for example.
Views can create controllers using Factory Method.
Under MVC, the observer pattern can be used to coordinate communication between different elements of your model.
For instance, suppose one core model component generates data and needs to notify other model components. You can facilitate this communication by registering the other models as listeners on the core model.
This behavior is independent of anything occurring in the view and controller layers.
No. It does no negate other object oriented and functional programming patterns.
MVC is an architectural design pattern, that you use on top of your existing codebase, when the pure OOP practices are not enough anymore to keep the code manageable.
The MVC pattern introduces additional constraints, that lets you organize the code and flow of information between the parts of your code.
Related
Recommendations I understood in Java (which has a lot of restrictions, # least for me), even with hibernate was to have separated layers
Entities like persons, children, users, etc...
DAO entities linked to database
Service providing entities and functionalities, where I'll do the SQL
WebService providing an interface over needs
As I'm starting with Eiffel and store, I'm facing some difficulties I face since ever in programming (hoping there's somebody in this earth who has not the same problem) I always want to generalize things more than necessary. Every time I do a copy-paste, I refactor and look for a solution which makes me able to write it one time... which takes time and time on the delivery of the software, but for me adds more quality and flexibility to the software. I'm actually working alone in a company where I'm going to be the lead developer and if the future wants we'll be more developers. The goal is to develop a platform of services in Eiffel, postgresql-odbc, and an Angular-web front-end.
I'd like to have the more generic pattern to be able to manage entities in the future with typical situations as:
Database entities
Relationships
one_to_one
one_to_many
many_to_one
many_to_many
# The point I'm now, I'm about to develop an architecture which ideally for me has:
DB_ENTITY which as relations: BAG[RELATIONSHIP[P,S]] where P=Primary and S=Secondary
Primary is P->DB_ENTITY when ONE and BAG[P] when MANY
A COMPANY on my design will inherit from DB_ENTITY and add relationships as a BRANCH. So I was thinking having in my COMPANY class branches: RELATIONSHIP[like Current, BRANCH]
The relationship classes would help me to create the CRUD SQL statements into the "service" layer in a more abstract manner.
when I try something more lightweight I find restrictions in the pattern where I have to repeat operations... thats a bit my difficulty
Do you think of any disadvantages of such model I'm creating out of the first shot of development?
Quenio dos Santos not wanting to create an account on stackexchange, I'll quote its answer which could be useful for others
I recommend the book:
https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1540350158&sr=1-2&keywords=domain+driven+design&dpID=51OWGtzQLLL&preST=_SY445_QL70_&dpSrc=srch
Not just because of the Repository pattern.
You should be able to implement reusable, abstract classes out of the
repository pattern if you want to get away from repetitive code. In
Java, MyBatis is a framework that helps with that. I really don’t know
if there is anything equivalent in Eiffel. I’m also a new Eiffel
developer.
Some pros-and-cons of the Repository pattern:
You define the SQL yourself. Some see it as a cons, but some see it as a pros, because you have clear understanding of the mapping from
the database to your classes, and it allows you to optimize your
queries, and join several tables into a single class, or smaller
number of classes, when approriate in your context.
More freedom on how you define your domain model. It can be quite different from the schema of your database. Your classes don’t have to
be just a set of anemic attribute holders of the tables in your
database, but they can have behavior and be useful and expressive in a
setting completely independent from your database.
ORM frameworks, like Hibernate, are sometimes hard-to-use for a new developer not very familiar with them. With the repository pattern,
because the mapping is so clear and available in your own code, it
tends to be easier to understand and debug.
You can also have different implementations of your repositories for different technologies, such as NoSQL databases. With ORM frameworks,
you tend to be stuck with a relational database, unless you rework
quite a bit of your dependencies on the ORM framework. It is easier to
encapsulate the data store technology behind repositories, and keep a
clean separation between your domain model and your database.
I’d say those are the main points. Having said that, these are very
general guidelines. I don’t have any experience with data persistent
in Eiffel, so I couldn’t say what are the best practices for Eiffel
developers. But I have a gut feeling that the repository pattern fits
well Eiffel because the original goal of the language was to build
more abstract, domain-rich class libraries, which is the purpose
behind the repository pattern. (By the way, I’m calling it a pattern,
but I’m not sure the author calls it that. The author would probably
call aggregates, entities and repositories, all kinds of classes used
in domain-driven design, all together a pattern.)
I have business logic like this that I need to reuse. My business logic is ordered like this:
User.Save();
Payroll.Calculate();
Mailer.Send();
Currently it's in my controller, but I want it to use in another controller. Where should I place that business logic and if there's design pattern what is it?
Sorry for noob question.
It's not that simple question as can looks like at first time. I would tell that answer to question WHERE will depend on few factors:
1. Does this piece of business logic interacts with other Services?
2. Does this piece of business logic need to interact with repositories?
3. Does this peace of business logic affects more then one entity?
And more. Depends on the answers to that questions I would choose one:
Put business logic directly to Entity if it really describes what Entity should really do or move it to Domain Model Service. Sometimes I use more layers to keep everything Clear, independent and simple.
One of the key concepts of DDD is Ubiquitos language and you should write your domain model in the way it represents your ubiquitos language in code. So, first think about your domain model and then about patterns to use to achieve the result.
I would recommend you to check Marco Pivetta's presentations, he often shows some real good DDD examples.
Use Application Service for such logic as plalx suggests.
Good explanation of different options for designing application services you can find in the last chapter of the follwoing book:
https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577
I would suggest also to look at hexagonal architecture:
http://alistair.cockburn.us/Hexagonal+architecture
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Hi guys let's say I have a new project an inventory system. I will be using Java. I go to my client gather some requirements and after I gather them I will model those requirements. Which should I do first? my class diagrams/domain models? or data model? and why? i would really like you opinion on this. what do you do in the real world in software development?
im using these techs: Java, Hibernate(ORM), Scrum(methodology), postgresql(database)
Don't do either one first. Create a domain (object) model and an ER model in parallel. They should be very similar except that the domain model is concerned with data and behavior while the ER model is concerned only with data.
However you need to be very careful to avoid a pitfall that many practitioners, even experts ones, fall into. That is the confusion between analysis and design. Both your domain model and your ER model should be analysis models and not design models. That means that they describe the problem and the requirements, and not the features you are going to add when you design the solution.
In particular, many of the ER diagrams you see in this forum are really relational data models, even though they use ER notation. And they incorporate design features like foreign keys and don't limit themselves to features that are inherent in the information requirements.
Failure to pin down the requirements fairly precisely before design begins is a major source of failure in large scale projects. In small scale projects, not so much.
My 2 cents...
Data tends to be longer-lived, more stable and ultimately more important than code. So your approach should be data-centric. If you structure and normalize your data properly (and ER diagram is important tool for doing that), the rest will naturally follow.
IMO you should definitely not start thinking about your Data Model first.
The reason is that it's up to your Domain Layer to address all business needs.
Your Domain Layer must be agnostic. It should not be tied to any specific technical implementation nor reference any kind of framework. It should be self contained and work alone. When designing your Domain Layer, do not think about persistence or even the way your data will be displayed. If you need methods to store your data, or methods to gather information from specific UI container like Session, just use Interfaces.
When designing a Data Model, you're tied to the RDBMS you're going to use to store your data. You will think about the way your schema will be structured to store and access data efficiently. But the thing is that the Business doesn't care about how good your queries will perform.
It's always a good thing to defer critical decisions like the UI, frameworks, database and so on, when you can. That way you focus only on business needs.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have read in "Design Patterns" book for the gang of four that the framework influences the overall architecture of the Application. Now I know for example when using .NET that you need to inherit from System.Windows.Form to make a form (Although I think I am having a big misconception here). But can anyone describe in code using any framework how does the framework affect the application architecture?
There are some interesting notes about the topic in Wikipedia:
Software frameworks consist of frozen spots and hot spots. Frozen
spots define the overall architecture of a software system (...).
These remain unchanged (frozen) in any instantiation of the
application framework. Hot spots represent those parts where the
programmers using the framework add their own code (...).
According to that, your application can be defined by the Frameworks you're using. For example, in the Java World using Struts frameworks implies that you're using an MVC architecture, or using Spring Framework forces you to apply the Dependency Injection Pattern. If Software Architecture is defined by software patterns, then some frameworks are pre-built patterns for you to utilize.
On the other side, no Software Application is made only by Patterns/Frameworks, an there's were the Hot Spots are usefull: they're ways that Software Frameworks offer to extends/use the frameworks capabilities and build an application according to your requirements and domain.
For example, let's say you're building a Web Application using Spring MVC Framework. After you configure the Framework in your project, every request for your application will be delegated to a class called DispatcherServlet. This class is built-in in the Framework and you shouldn't modify it, so it's a perfect example of a Frozen Spot. The DispatcherServlet will look-up your project configuration and delegate request processing to a Controller. The Controller is typically a class made by the programmer and has the responsability to process the request. So your hand-made controller it's a Hot Spot for you to extend the Framework.
And the DispatcherServlet is an Implementation of the Front-Controlller Patttern, and the Controller usage is typicall of an MVC application; so your application is highly defined by the framework you're using.
I must say that a clean Architecture(also Design Patterns) does not depend on which frameworks, toolkits or library are being used. An architecture describes the high level structure of a software system(layers and tiers), not in details how it is implemented. it's a set of principles that help us to achieve some specific goals such as security, usability, extensibility, reliability, maintainability, availability... Let's see a simple example:
Model–view–controller (MVC) is a software architecture(or design pattern) that separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes. The central idea behind MVC is code reusability and separation of concerns. You can apply MVC using many programming languages or frameworks like ASP.Net MVC, Java Strut, PHP DRY, CAKEPHP....
There are different approaches in ways of passing, storing or evaluating data in different frameworks. IF you're working with a Windows Form application, you can reach your view elements from anywhere of the project, since they are all in the computer's local memory and nowhere else.
However, if you're working with an ASP.NET application, there are different sides consuming the project, client and server and things get more complex. The design you're making has almost nothing common with Forms.
If you're working with an ASP.NET MVC application, there are three tiers: ModelViewController, and operations are divided into these and from now on, you need to do your design in a way that fits with these tiers. You have database table-object relations provided by MVC which could change the design totally.
Also programming language lying beneath the program changes the design, as it can be functional, object-oriented etc.
In short, this is not a constructive question. You'll figure out this questions answer after working with different programming languages and technologies.
I would like to use a Sqlite datbase in an iphone application. The example in the book I am reading has the controllers directly calling into CoreData objects.
Coming from MVC/MVP in .NET to me this is akin to opening a SQL Connection in a button event handler. I would typically have a repository that handled the details of retrieving/persisting the model.
1) Is it the norm to use CoreData functionality directly in a Controller?
2) Is extracting my domain model into separate classes that get translated back and forth to the persistence layer not a good idea on the iPhone (in regards to performance, memory, expected project organization, etc)?
3) Will creating a repository layer work well on an iPhone?
Going with the SmallTalk background Objective-C and the MVC approach of iPhone applications I was expecting to leverage Domain Models, Repositories, IoC, etc.
Is that just not realistic? Are the author and I just on different pages? Thanks for any input.
iPhone SDK does follow the MVC pattern, but also many others (delegate). So it may not be as strict as other languages you mentioned. To answer your questions:
You will inevitably have some kind of access to your Models from your Controller. So long as the implementation of these actions is handled within the Model then you are following the MVC pattern. This is provided by the CoreData Framework. So in the end, it is your DAO, ActiveRecord, etc.
You can generate the Model classes (Model.m/h) if you wish to add extra functionality. However, CoreData typically builds them for you on the fly.
I don't quite understand this without a .NET background, but I think my answer to your first question may have answered it indirectly.
I can't speak to the book you are reading, but it may be best for you to see some additional references. Check out the Introduction to Core Data in the ADC's Reference Docs as well as one of the sample projects - CoreDataBooks.
Yes, Core Data is typically used as the model. If I understand what you are saying correctly, you expect a layer between the actual data store and the controller. Core Data is that layer -- it (sometimes) is implemented in sqlite, so that you never actually use sqlite directly. This is I think the source of your confusion -- you're not supposed to use both in the same project for the same data.