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.
Related
I've started using EF and LINQ in a project and I'm trying to decide on the best approach/pattern to use. Until now I've been using a custom persistence framework that was based on DataSets and XML configuration. Basically it was a VS Custom Tool that would read the XML configuration file and the DataSets and would generate Object Oriented classes with all the necessary properties/associations/methods. This auto-generated classes then were used from the UI and I had the flexibility to expose only what the UI would need.
Now with EF and LINQ, I'm not comfortable with the idea that the UI can use directly the auto-generated classes and all the LINQ stuff. It seems that this approach would have a very tight integration between UI and the database.
So I'm looking for some pattern that would "hide" all the EF and LINQ goodies and basically limit what the UI can do. Is there any standard way to do this?
What you're looking for is an n-tier application. It's not so much a pattern as an architecture. You break your app up into 2 or more pieces, typically 3 composed of UI, business and Data. You might implement this through other patterns such as the Facade or Repository patterns to keep a strong seperation of concerns.
You might also use a Service Layer, which could be implemented by a facade or as a web service.
You would, ideally, pass data through objects called DTO's or Data Transfer Objects, and you might adapt those DTO's by using a view model in your UI (not to be confused with MVVM which another poster erroneously mentioned.)
Beyond that, much of it depends on the type of app you're buiding. Desktop app, server app, web app, etc..
The pattern you're looking for is, in general, Model-View-ViewModel, or MVVM.
Here's a tutorial that seems to hit on the high points of the design pattern: http://csharperimage.jeremylikness.com/2010/04/model-view-viewmodel-mvvm-explained.html
(I had a hard time titling the question so feel free to suggest edits)
Here's the situation: we have just started building a system which is comprised of two integrated MVC 3 web applications running on Azure with a shared AzureSQL database. There are many reasons for running two apps instead of one and I'd rather not get into that...
Originally, database was created code-first from the MVC application "A". 75% of entities from all created will be relevant to application "B" plus application "B" will need a few entities specific to it.
Currently, the entities-defining classes have been extracted into a class library so within the application "A" solution to allow for reuse in application "B". But I am still unsure how to go about adding entities required for application "B"...
The question is: what is the best way to manage the database development/management in this situation? Specifically, where should the definition of entities be? Should we just have a separate db project defining the database and work db-first? (with this option being my preferred at this stage).
Since both of the devs (me and the other dev) working on this are new to MVC and EF, any advice would be much appreciated.
Without seeing what you have its not entirely mapping here in my brain - but I think I may have an idea on this.
Can you create an additional projects containing your models (data access layer) that has your entity framework edmx (or code first) and poco templates installed. This project will be shared by both applications - ie both projects get this assembly and both have the ef connect string in their web.configs.
Another approach is to put all code first into a single project (whatever.domain, whatever.models) etc. Your mapping code then goes into your DataAccess project
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove();
modelBuilder.Configurations.Add(new CustomerMap());
...
}
You now have shared poco classes and a single data access layer.
Some treat their poco classes as their domain objects (theres no problem with this) and their business logic goes in the poco classes. This is fine as long as your poco objects themselves remain persistent ignorant and ideally you don't want to reference implementation specific components in your poco classes. For a good writeup here see:
POCO - if POCO means pure .net class with only properties, where i can write validations in MVC
Personally I like db first and then reverse engineer it using the EF power tools to have a code first model as if you ever want to integration test it, you can simply create the db for your integration tests and remove it when done.
When developing with MVC with an ORM
I dont like the idea that the ORM will make changes in my DB.
My application is a data driven application and the DB is the the first thing i created.
Isn't that an overhead to maintain the data scheme both in the model and in the DB?
How do i manage it?
Any ORM that is more suitable to this kind of work method?
I dont like the idea that the ORM will make changes in my DB
ORM don't have to make any changes in your database structure. If you have existing database you can simply use it without requiring any automated changes.
Isn't that an overhead to maintain the data scheme both in the model and in the DB?
How do you want to present your data in MVC? Are you going to use classes representing your data from the database? If yes then you have a reason why ORM exists. ORM maps relational data from database to classes = it loads them for you and persists them for you (= you don't have to deal with database access and SQL). If you are going to use object oriented strongly typed approach then ORM will not be overhead for you.
If you are not going to use such approach you don't have to use MVC. Just use ASP.NET with SQL data sources or ASP.NET dynamic data.
Any ORM that is more suitable to this kind of work method?
You have no special method.
Almost every ORM has some support tools or extensions which allows you creating basic mapping and sometimes also classes from existing database. In EF you will simply add Entity Data model to your project and in wizard selects tables you want in your application.
Sure the last paragraph was simplified. Each ORM has learning curve and its specialties so it will not be so "simple".
For .NET 4 Entity Framework, the tooling let's you go both directions; generate a database from a model and generate a model from a database. These features give you flexibility when implementing your change management protocols. I'm not sure what options are available for NHibernate.
Entity Framework references:
http://msdn.microsoft.com/en-us/library/bb386876.aspx
http://msdn.microsoft.com/en-us/library/bb399249.aspx
http://www.simple-talk.com/dotnet/.net-framework/entity-framework-4460---learn-to-create-databases-from-the-model/
A Stackoverflow comparison of the two:
Deciding between NHibernate vs Entity Framework?
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 have used the Entity Framework to start a fairly simple sample project. In the project, I have created a new Entity Data Model from a SQL Server 2000 database. I am able to query the data using LINQ to Entities and display values on the screen.
I have an Oracle database with an extremely similar schema (I am trying to be exact but I do not know all the details of Oracle). I would like my project to be able to run on both the SQL Server and Oracle data stores with minimal effort. I was hoping that I could simply change the configuration string of my Entity Data Model and the Entity Framework would take care of the rest. However, it appears that will not work at seamlessly as I thought.
Has anyone done what I am trying to do? Again, I am trying to write an application that can query (and update) data from a SQL Server or Oracle database with minimal effort using the Entity Framework. The secondary goal is to not have to re-compile the application when switching back and forth between data stores. If I have to "Update Model from Database" that might be ok because I wouldn't have to recompile, but I'd prefer not to have to go this route. Does anyone know of any steps that might be necessary?
What is generally understood under the term "Persistence Ignorance" is that your entity classes are not being flooded with framework dependencies (important for N-tier scenarios). This is not the case right now, as entity classes must implement certain EF interfaces ("IPOCO"), as opposed to plain old CLR objects. As another poster has mentioned, there is a solution called Persistence Ignorance (POCO) Adapter for Entity Framework V1 for that, and EF V2 will support POCO out of the box.
But I think what you really had in mind was database independence. With one big configuration XML that includes storage model, conceptual model and the mapping between those two from which a typed ObjectContext will be generated at designtime, I also find it hard to image how to transparently support two databases.
What probably looks more promising is applying a database-independent ADO.NET provider like the one from DataDirect. DataDirect has also announced EF support for Q3/2008.
http://blogs.msdn.com/jkowalski/archive/2008/09/09/persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx
The main problem is that the entity framework was not designed with persistence ignorance in mind. I would honestly look at using something other than entity framework.