I would like to know what would be the way to model a Class diagram of a Struts2 Web App.
I was thinking about this:
Since Struts2 uses a MVC architecture, I would have for example, 3 classes:
CatalogueThemeController, CatalogueThemeModel, and a JSP to display the view of that Catalogue.
How do I have to make the relationships between the classes? Thanks in advance for your help.
John Smith
How do I have to make the relationships between the classes?
After you wrote the classes, you can generate the UML digram using any UML generator application. There are a lot of UML generator applications, find one that suit to yourself. For me, I'm using eclipse as the Java IDE and eUML2 seem does its job in generating the class diagram.
Now you have action controller and model in your web app which reside in the java package? You can generate them easily in the UML class diagram and you can show the relationship between the classes (in your case, 3 classes). The class diagram can show dependencies, inheritances or associations. Think that is good enough to show relationship between classes in your struts webapp.
Hope it helps you and answer your question. I've generated my project which using strut and check out this diagram
Related
I have a project I aim to build by laravel framework, but I need to draw the analysis of the project , including the UML diagram, the laravel framework comes with its classes that operates the project (autoloaders and service providers), but my work will be focused on the customizable area of the laravel framework , thus, making a model, middleware, controller, migration.
So how do I clarify in the UML that the shown classes are built on top of laravel framework, by extending laravel classes, without mentioning the whole UML analysis of the framework?
There are two options:
Model the Laravel classes. Only specify the class names, not attributes/operations. Put them in a package called 'Laravel'. Then model your own classes and use generalization relationships to the Laravel classes.
Define a stereotype for each Laravel class you use, e.g. ≪BusServiceProvider≫ and apply these stereotypes to your classes.
I would prefer option 1. I usually show these classes using a special background color.
I have been jumping between articles and questions but i can't seem to find the information i want.
When i started learning about MVC, tutorials and articles pointed out that:
*Models: is where you business logic goes
*Controller: is where data-access and handling request/respond happens.
I have been working with MVC for a while now and I wanted to migrate an old simple project to MVC. In the project i have a business and data access layers.
After reading about N-Tier MVC architecture, my understanding changed.
The model in which i usually presumed to be the business domain has now changed to be more of a presentation depending on views. Its true that models reflects the business entities but it acts as another layer over it.
So my question here is the following: Assume that i have an MVC project and i have another two projects, business and data-access. Is the relation in this manner right ?
*A model, will mostly have the same properties as in its corresponding business entity.
*The controller will call the DataAccess-Layer to retrieve data, the data will be returned as business object which will be mapped into a model and then returned into a view.
Model not always corresponds to business entities. Because models in MVC used to reflect entities that will be sent to view. So they may be little bit sipmlier than domain business entities. It is correct that your domain model will be mapped to mvc model.
Second statement I agree 100%.
Is the relation in this manner right ?
My answer is that depends on your project scale and team size, But let me explain you my projects architecture.
MVC: A presentation layer, It is the startup project of the application.
Common: This is a class library which contains a set of core classes, such as helpers, base classes, ... This project is referenced to all other projects.
Repositories: For reading from and writing to a database, I've created a project and named it repositories. This project is a combination of repository and the Unit of Work pattern. Implementing these patterns can help insulate your application from changes in the data store.
Test: Unit tests are written in this project.
Hope this will help you.
I have been reading countless articles about how to architect a new MVC 3 application using best practices.
90% of the articles combine the EF EDMX files into the same project as the MVC app. Those that do seperate these items into their own projects don't clarify which project each goes into and what references each project has. Usually they consist of code snippets that are great to teach how to do a specific function, but don't tell me how to architect the solution.
I believe that I need at least 5 projects in my solution. Can anyone tell me if I have the correct layout here?
Data Access Layer - Contains the EF EDMX files. (Perhaps the DBContext auto-generated code?)
Business Layer - Contains the IRepository and Repository classes, UoW classes, as well as the business logic for the domain. - Contains reference to DAL.
ViewModels - Contains the viewmodels that will use AutoMapper to go between my DAL and the presentation layer. - Contains reference to DAL.
MVC 3 App - Standard MVC 3 app. Contains references to the BusinessLayer and the ViewModels projects.
Test - Unit testing.
Does this look right? Can anyone point me to a good article that uses n-tiered development with ViewModels, AutoMapper, Repository patterns and EF4?
When looking at what project to put something in, it helps to think about how you are going to be deploying your code. Put code that will ship together in the same project and then use namespaces to separate it out logically into separate tiers. For most of the projects I work on it tends to be pretty simple with 3 projects.
Business Layer
Domain/Business Model and Services
Data Access Layer
MVC App
View Models
Automapper
Controllers
Views
Tests
Unit tests
I like the following
Domain - contains models and ViewModels
Services -business logic and viewmodel hydrating (ie population) code
Contracts or interfaces - repository interfaces, unit of work, IContext, and ICache
Web site
DataAccess - concrete implementation of entity framework
Some include their AutoMap code directly as an action filter as an attribute inside the web project. My automap code is done in the services project (but again this is up to you) unless I can use the attribute to do it in the controller.
btw see Jimmy's nice attribute here:
http://lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models/
What you have outlined above is fine as well though. This is a very subjective matter. My general recommendations are that 'if someone can open a project and have an idea where to look for something, you are likely doing it correctly'
The way I usually do it:
Model project - Contains the model generated from the db and the context.
POCOs project - Contains the Business entities
Controller project - similar to your repository
MVC3 project - front end, INCLUDING view models and repository classes that include automapper equivalencies.
Unit tests
Architecture is technology independant, whether you are using EF, Hibernate, MVC, webforms etc... And you usually combine patterns. Besides is mostly depends on each particular project.
Regarding to best practices, when talking about EF, I can't link you to the source I use because I use a book. However I'll link you to the author's blog, it's Julie Lerman's Programming Entity Framework.
I am new to Java Server Pages (JSP) but I am pretty used to Unified Modeling Language (UML).
I want to start to develop a Web Application that uses the Design Pattern Model–view–controller (MVC).
For instance I want to build the adequate UML architecture for the example given on this MVC + JSP Tutorial.
This Tutorial builds a simple application and as the author describes, it is a "web application is a Coffee advisor, the user will input the type of Coffee and get back some advise"
By adequate UML architecture, I mean Sequence Diagrams, Class Diagram, Package Diagrams etc.
How should I proceed?
This question could seem out of topic because UML is unfortunately always associated to Model Driven Development.
I mean that if you use Persistence annotations in your class diagram which would generate the code including Hibernate annotation and then the database from the code then UML can deal with MVC and not only with MDD.
This is strange but I prefer MVC to MDD because this is more realistic and save a lot of time at coding and deployment level. This is also better if you need multiple iterations between deliveries and requirement changes.
You have many tools which allows ORM but I think only Omondo has investigated the UML with ORM at object level oppose to the other tools more MDD oriented. I mean generate a database from a model using code generation while Omondo is only using Hibernate annotations and then let Hibernate to create the database. I prefer to use UML and Hibernate and not MDD to generate my Database because when using MDD once you have generated your database you can not change the code manually. Everything should be done at model level. This is too much constraints and sometimes impossible. Omondo and Hibernate allows me to change my code as many times as needed.
I've been using ASP.net MVC for about two years now and I'm still learning the best way to structure an application.
I wanted to throw out these ideas that I've gathered and see if they are "acceptable" ways in the community to design MVC applications.
Here is my basic layout:
DataAccess Project - Contains all repository classes, LINQ-to-SQL data contexts, Filters, and custom business objects for non-MS SQL db repositories (that LINQ-to-SQL doesn't create). The repositories typically only have basic CRUD for the object they're managing.
Service Project - Contains service classes that perform business logic. They take orders from the Controllers and tell the repositories what to do.
UI Project - Contains view models and some wrappers around things like the ConfigurationManager (for unit testing).
Main MVC Project - Contains controllers and views, along with javascript and css.
Does this seem like a good way to structure ASP.NET MVC 2 applications? Any other ideas or suggestions?
Are view models used for all output to views and input from views?
I'm leaning down the path of making view models for each business object that needs to display data in the view and making them basic classes with a bunch of properties that are all strings. This makes dealing with the views pretty easy. The service layer then needs to manage mapping properties from the view model to the business object. This is a source of some of my confusion because most of the examples I've seen on MVC/MVC2 do not use a view model unless you need something like a combo box.
If you use MVC 2's new model validation, would you then validate the viewmodel object and not have to worry about putting the validation attributes on the business objects?
How do you unit test this type of validation or should I not unit test that validation messages are returned?
Thanks!
Interesting.
One thing I do differently is that I split off my DataAccess project from my Domain project. The domain project still contains all the interfaces for my repositories but my DataAccess project contains all the concrete implementations of them.
You don't want stuff like DataContext leaking into your domain project. Following the onion architecture your domain shouldn't have any dependencies on external infrastructure... I would consider DataAccess to have that because it's directly tied to a database.
Splitting them off means that my domain doesn't have a dependency on any ORM or database, so I can swap them out easily if need be.
Cheers,
Charles
Ps. What does your project dependency look like? I've been wondering where to put my ViewModels. Maybe a separate UI project is a good idea, but I'm not entirely sure how that would work. How do they flow through the different project tiers of your application?