Can anyone provide me with a web link that shows a correct approach of n-Layered design with example source-code in VS2005 and C#?
I am confused in one point, If I am creating layers like the following:
UI
|
Business Logic
|
Data Access
then how can I achieve true OOP?
Coz In OOP all activities should be encapsulated within an Object.
According to my thought, this should be layered like this:
UI
|
Business Objects
|
Business Logics
|
Data Access
But when trying to design layers like this I experienced Circular Reference Problem.
One of my buddy told me that, he solved this problem with Reflection.
So what is the industry-standard approach in separating a c# application into layers?
And a burning question is, which layer hosts the OR-Mapping?
alt text http://amrelgarhy.com/files/uploads/9-1-2009%208-58-14%20PM.png
And Some times goes like this:
alt text http://amrelgarhy.com/files/uploads/9-1-2009%208-59-14%20PM.png
So as you see in the 2 previous diagrams, the ORM located in the data access layer
Related
I'm working on an eclipse RCP application, using a third-party domain model based on EMF, and a GEF editor for editing.
GEF uses the MVC pattern, which would be fair enough if I didn't have to use a specific layout for drawing the model graph on the editor view. The domain model I am using includes no visual information whatsoever (which in itself is a good idea), but I'd like to be able to assign coordinates to Figures in their EditParts. This would make it much easier for me to calculate the position of the figure in the layout.
Now I have stumbled upon the Presentation Model Pattern by Martin Fowler, which seems just about the thing I was looking for. I have also found a - old-ish - tutorial on RCP UI testing (German only), which uses this pattern in an eclipse RCP context.
Now I'm wondering: is it generally possible to use PM in a GEF context, seeing that GEF explicitly uses MVC? Is MVVM an alternative?
Please note that I am prevented from using GMF for a number of reasons.
Many thanks!
Yes, it's definitely possible, and you have two choice.
First - is implement you own graphical notation model. I would suggest you using appreach like:
modelElement : ModelElement 1..1
x : int 1..1
y : int 1..1
Then load two models in EditingDomain (EMF will resolve cross-document references for you), create all missing Graphical Notation Elements e.t.c...
The other option is to use GMF or Graphiti. They have the model you're looking for out of the box, which will greatly simplify you life. At the cost of learning yet-another-monster-framework (in case of GMF). Graphiti, is easy (relative to GEF/GMF), but IMO is's less flexible. GMF, btw, will give you a 'free' TransactionalEditingDomain, which will handle all the commands, undos and redos for you. So, as in comments to you previous question, I would suggest you using GMF.
Oh, sorry, I didn't noticed what you wrote about GMF.
Then, the second option is to have Graphical Model inherit from Domain Model, and then code you GEF editor against this model.
I've mulled over Design Patterns for some time now and I am just starting to see how I might actually begin incorporating some of these more deliberately in my development work. However, I am still confused about their treatment of MVC in the beginning of the book and how it relates to the rest of the book.
Most of the frameworks I have worked with - Spring, Yii, ASP.NET, and even Objective-C Cocoa (UIKit) - cater to the MVC paradigm. I get MVC because to me it is a useful way of classifying objects and how they should message or interact with each other. Plus, these frameworks kind of force it upon you even if you are not setting out to think in the MVC way.
I also feel that I understand the premise of Design Patterns: they really don't like subclassing, they love abstract interfaces, and they strive for loose coupling. I can't say I fully understand all of the patterns yet or how they are useful, but I am getting a feel for it.
My question is this: what is the interplay between MVC and design patterns? What were they getting at in the first chapter of the book with the MVC application example? Are certain design patterns just not relevant in the MVC paradigm? I wonder, for example, how the Command pattern is supposed to fit into MVC. It seems incredibly useful, but do we create a CommandModel and CommandController to send to other controllers? Do we just create a Command object as prescribed in the book? Basically, I am wondering if the ideas of MVC and Design Patterns are wholly disjoint and I just don't understand, or if there are some patterns that do not fit into the mold.
My personnal opinion is that MVC is a simplified version of the Observer Pattern which is a simplified version of the Mediator Pattern.
MVC: One Model, One view, the Controler manages the communication between them.
Observer Pattern: One Model, Multiples views ( observers/subscribers ), and the publisher manages the communication
Mediator Pattern: Several different Models, Several views, and the mediator manages the communications between them.
The MVC in the GoF book is for the desktop, it uses the observer pattern to update views. The command example in the GoF book is for an editor.
There are other flavors of MVC where the use of other design patterns may not be obvious:
What is the difference between MVC and MVVM?
Presentation abstraction control
The GoF book says:
...
Taken at face value, this example reflects a design that decouples views from models. But the design is applicable to a more general problem: decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others. This more general design is described by the Observer (page 293) design pattern.
Another feature of MVC is that views can be nested. For example, a control panel of buttons might be implemented as a complex view containing nested button views. The user interface for an object inspector can consist of nested views that may be reused in a debugger. MVC supports nested views with the CompositeView class, a subclass of View. CompositeView objects act just like View objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views.
Again, we could think of this as a design that lets us treat a composite view just like we treat one of its components. But the design is applicable to a more general problem, which occurs whenever we want to group objects and treat the group like an individual object. This more general design is described by the Composite (163) design pattern. It lets you create a class hierarchy in which some subclasses define primitive objects (e.g., Button) and other classes define composite objects (CompositeView) that assemble the primitives into more complex objects.
MVC also lets you change the way a view responds to user input without changing its visual presentation. You might want to change the way it responds to the keyboard, for example, or have it use a pop-up menu instead of command keys. MVC encapsulates the response mechanism in a Controller object. There is a class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one.
A view uses an instance of a Controller subclass to implement a particular response strategy; to implement a different strategy, simply replace the instance with a different kind of controller. It's even possible to change a view's controller at run-time to let the view change the way it responds to user input. For example, a view can be disabled so that it doesn't accept input simply by giving it a controller that ignores input events.
The View-Controller relationship is an example of the Strategy (315) design pattern. A Strategy is an object that represents an algorithm. It's useful when you want to replace the algorithm either statically or dynamically, when you have a lot of variants of the algorithm, or when the algorithm has complex data structures that you want to encapsulate.
MVC uses other design patterns, such as Factory Method (107) to specify the default controller class for a view and Decorator (175) to add scrolling to a view. But the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns.
...
MVC is a pattern. But it only covers a small aspect of a web application. Another common pattern that gets used with MVC is the Repository. These are more architectural patterns.... their scope has a bigger impact on the overall project.
the GOF patterns will introduce themselves in little ways all over the place. They can help build MVC infrastructure depending on design choices. eg, Strategy gets used a lot so you can plug in different ways of doing things like "authentication" etc.
You don't have to use the patterns as they are, they don't even have to be the exact same code structure. Its more the design principle / goal of the pattern that you employ in the design.
MVC is an architectural pattern. It perfectly fits with other design patterns like Command Pattern. But you do not apply patterns just because they exist and they are written in an authoritative book. You apply patterns when you have a programming/design problem and there is a way to solve that problem that was discovered by someone else and was written down. The way to solve a problem is a pattern. For example, you have an application that saves data to the database. Data to be saved is quite complex: some records must be inserted, some records updated and some deleted. The sequence of steps is important because the records to be inserted into one table depend on records to be inserted into another table. So, a database transaction must be used. One of possible ways to implement the transaction is to use Command Pattern. The way to do it is very well explained in Larman's "Applying UML and Patterns" book (chapter "Designing a Persistence Framework wth Patterns", section "Designing a Transaction with the Command Pattern" - scroll down to the page 556). PersistentObject is an abstract Model class there. All other Model classes extend it. In that example MVC is implemented in the UI, Application and Domain layers but Command is implemented in the Persistence layer. These patterns help to solve different problems and they are mutually supportive in that example.
i'm wondering if there is a pattern how to separate the domain logic of a class from the ui responsibilities of the objects in the domain layer.
Example:
// Domain classes
interface MachinePart
{
CalculateX(in, out)
// Where do we put these:
// Draw(Screen) ??
// ShowProperties(View) ??
// ...
}
class Assembly : MachinePart
{
CalculateX(in, out)
subParts
}
class Pipe : MachinePart
{
CalculateX(in, out)
length, diamater...
}
There is an application that calculates the value X for machines assembled from many machine parts. The assembly is loaded from a file representation and is designed as a composite. Each concrete part class stores some data to implement the CalculateX(in,out) method to simulate behaviour of the whole assembly. The application runs well but without GUI. To increase the usability a GUi should be developed on top of the existing implementation (changes to the existing code are allowed). The GUI should show a schematic graphical representation of the assembly and provide part specific dialogs to edit several parameters.
To achieve these goals the application needs new functionality for each machine part to draw a schematic representation on the screen, show a property dialog and other things not related to the domain of machine simulation. I can think of some different solutions to implement a Draw(Screen) functionality for each part but i am not happy with each of them.
First i could add a Draw(Screen) method to the MachinePart interface but this would mix-up domain code with ui code and i had to add a lot of functionality to each machine part class what makes my domain model hard to read and hard to understand.
Another "simple" solution is to make all parts visitable and implement ui code in visitors but Visitor does not belong to my favorite patterns.
I could derive UI variants from each machine part class to add the UI implementation there but i had to check if each part class is suited for inheritance and had to be careful on changes to the base classes.
My currently favorite design is to create a parallel composite hierarchy where each component stores data to define a machine part, has implementation for UI methods and a factory method which creates instances of the corresponding domain classes, so that i can "convert" a UI assembly to a domain assembly. But there are problems to go back from the created domain hierarchy to the UI hierarchy for showing calculation results in the drawing for example (imagine some parts store some values during the calculation i want to show in the schematic representation after the simluation).
Maybe there are some proven patterns for such problems?
Agree with #Marjin, and to generalise his answer. What you need is Model-View-Controller of which MVP and MVVM are variants. From your comments I think you understand that, but need to understand how to implement the pattern. Without knowing your language & target architecture it's hard to give absolute specifics. Notwithstanding, I'd start with the Observer pattern (link has sample code).
The problem you're dealing with is how to provide observable access from the domain to the UI - without encumbering the domain with UI-specific code. Observer provides a means to do that. It does require domain changes, in particular to enable registration of observers and notification of changes. However there's nothing GUI-specific in that so it stays well encapsulated.
hth.
PS: If your app is a typical thin-client web app you'll need to modify the approach. And beware: lots of web app frameworks are advertised as "MVC", but the implementation is architecturally quite different to the Observer pattern.
You can take a look at the model-view-presenter (mvp) and model-view-viewmodel (mvvm) patterns.
Fowler's presentation model includes two sample applications; it also might be of interest to you.
I think that investigating these patterns will give you some ideas on how to continue. Mvvm looks a lot like your current solution; so i'd start there if I were you.
Maybe a View Helper can help. It's not a C++, but a Java EE pattern, but in your case it will definitely separate your domain objects from their presentation details...
I have another programmer who I'm trying to explain why it is that a UI component should not also be a data-structure.
For instance say that you get a data-structure that contains a record-set from the "database", and you wish to display that record-set in a UI component within your application.
According to this programmer (who will remain nameless, he's young and I'm teaching him...), we should subclass the data-structure into a class that will draw the UI component within our application!!!!!!
And thus according to this logic, the record-set should manage the drawing of the UI.
******Head Desk*****
I know that asking a record-set to draw itself is wrong, because, if you wish to render the same data-structure on more than one type of component on your UI, you are going to have a real mess on your hands; you'll need to extend yet another class for each and every UI component that you render from the base-class of your record-set;
I am well aware of the "cleanliness" of the of the MVC pattern (and by that what I really mean is you don't confuse your data (the Model) with your UI (the view) or the actions that take place on the data (the Controller more or less...okay not really the API should really handle that...and the Controller should just make as few calls to it as it can, telling it which view to render)) But it's certainly alot cleaner than using data-structures to render UI components!
Is there any other advice I could send his way other than the example above? I understand that when you first learn OOP you go through "a stage" where you where just want to extend everything.
Followed by a stage when you think that Design Patterns are the solution every single problem...which isn't entirely correct either...thanks Jeff.
Is there a way that I can gently nudge this kid in the right direction? Do you have any more examples that might help explain my point to him?
Have you heard of Martin Fowler?
Separating User Interface
Code
Anyway, if he wants to go further in that direction of adding render methods to his data controls, have him look at "loose coupling". It's okay to create some generic type of interface that gets him halfway there, but the UI component should take it the rest of the way.
This boils down to functional vs. non-functional responsibilities. What the data structure does and how it's visualized are two completely separate things -- essentially the root of the MVC pattern.
There's also a notion of circular dependencies here. Since the UI must know about the data structures, if you allow the data structures to then depend on the UI, you've got yourself a nice little ball of mud.
Generally on the point of decoupling:
Not only can there be different components of the UI rendering the same data structure. You may even have completely different UIs (Web, Desktop Application, ...) Now of course, you could subclass Person with WebPerson and DesktopPerson (this already sounds wrong, doesn't it? The naming is simply not about the kind of Person - it's about something else).
Each UI could work on different kinds of Persons, e.g. Teacher and Student. So we get WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher and DesktopStudent.
Now let's say, WebPerson defines the method "drawAddressFields()" to draw a web version of the address fields. But since WebTeacher has to derive from Teacher to use the additional data field "salary" (and let's assume single inheritance), it must implement "drawAddressFields()" once again!
So maybe the argument of "this will cause much more work" will help to create some motivation :-)
BTW, it will automatically lead to creating some delegate that implements the code of drawAddressField(), which will then evolve to creating a component that does the drawing separately from the data structure.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I've heard the term MVC (Model View Controller) tossed about with a ton of Buzz lately, but what really is it?
You might want to take a look at what Martin Fowler has to say about MVC, MVP and UI architectures in general at Martin Fowlers site.
I like this article by Martin Fowler. You'll see that MVC is actually more or less dead, strictly speaking, in its original domain of rich UI programming. The distinction between View and Controller doesn't apply to most modern UI toolkits.
The term seems to have found new life in web programming circles recently. I'm not sure whether that's truly MVC though, or just re-using the name for some closely related but subtly different ideas.
MVC is a design pattern originally pioneered in the olden days of smalltalk.
The concept was that a model would represent your application state and logic, and controllers would handle IO between "Views".
A View was a representation of the state in the model. For example, your model may be a spreadsheet document, and you may have a view that represents it as a spreadsheet and a view that represents it as a pivot table.
Modern MVC has been polluted with fake MVC web junk, so I'll let others answer that.
Here is a naive description of MVC : http://www.devcodenote.com/2015/04/mvc-model-view-controller.html
A snippet:
Definition : It is a design pattern which separates an application into multiple layers of functionality.
The layers:
Model
Represents data.
It acts as an interface between the database and the application (as a data object).
It will handle validations, associations, transactions etc.
Controller
It gathers and processes data.
Handles code which does data selection and data messaging.
View
Displays output to the users.
MVC Design Pattern:
4 parts = User, View, Controller, Model.
User:
- sees the View and uses the Controller.
Model:
- holds the data and updates the Model that there is new data/state.
View:
- displays the data that the Model has.
Controller:
- takes the request from the user to get or set information, then communicates with either the View or Model, resp.
- it "gets" via the View.
- it "sets" via the Model.
As the tag on your question states its a design pattern. But that probably doesn't help you. Basically what it is, is a way to organize your code into logical groupings that keep the various pieces separate and easily modifiable.
Simplification:
Model = Data structure / Business Logic
View = Output layer (i.e HTML code)
Controller = Message transfer layer
So when people talk about MVC what they are talking about is dividing up there code into these logical groups to keep it clean and structured, and hopefully loosely coupled. By following this design pattern you should be able to build applications that could have there View completely changed into something else without ever having to touch your controller or model (i.e. switching from HTML to RSS).
There are tons and tons of tutorials out there just google for it and I'm sure you'll turn up at least one that will explain it in terms that click with you.
Wikipedia seems to describe it best so far:
http://en.wikipedia.org/wiki/Model-view-controller
Model-view-controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application and the business rules used to manipulate the data; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements
The MVC or Model-View-Controller User Interface Paradigm was first described by Trygve Reenskaug of the Xerox PARC. In first appeared in print in Byte magazine volume 6, number 8, in August of 1981.
This What is MVC blog article on Oreilly has you covered.
MVC is a software architecture pattern that separates representation from user interaction.
Generally, the model consists of application data and functions that interact with it, while the view presents this data to the user; the controller mediates between the two.
It is a way of separating the underlying functionality of your application (model) from the way it interacts with the user (view). The controller coordinates how the model and view talk to each other.
Whilst it is all the rage at the moment, it is important to remember that preventing the model itself being able to determine exactly how its data is presented to the user can seen as a negative thing. The most obvious example is with HTML. The original intention of HTML was that there should be a clear separation of the model (HTML) from the view (rendered webpage) via a controller (the browser). There has been such a backlash against this original intention that browsers are criticised if they do not render a page pixel perfect to the designer's desired view.
MVC is a way to partition a user interface element into 3 distinct concepts. The model is the data on which the interface operates. The view is how the element is represented visually (or maybe audibly?). The controller is the logic that operates on the data.
For example, if you have some text you want to manipulate in a UI. A simple string could represent the data. The view could be a text field. The controller is the logic that translates input from the user - say character or mouse input - and makes changes to the underlying data model.
Like many have said already, MVC is a design pattern. I'm teaching one of my coworkers now and have explained it this way:
Models - The data access layer. This can be direct data access, web services, etc
Views - The presentation layer of your application.
Controllers - This is the business logic for your application.
This pattern enhances test-driven development.