We are creating a website from scratch and the will be created in MVC 4.0 With EF4.0
And we wish to create a common data access layer using EF and expose the EF using WCF. As the EF contains the CodeLogic we wish to separate the EF from the client calls. The client has to call the WCF via POCO object and the WCF will inturn return some kind of results using POCO.
And my question is this kind of logic is ok. How can I convert POCO to EF and vice versa.
Thanks for your time and patience
First of all, I don't know if it is a good idea to expose Entities directly from a webservice. Maybe you wanna use a Data Transfer Object and maybe you wanna use a WCF REST or a WebApi (webservice is quite outdated). That would be a good idea if you have your Business logic inside the WebService. If not, it's quite weird to use Entify Framework capabilities and then hide all the advantages behind a webservice.
Anyway, there is a awesome tool for converting from one object to another, it's called automapper.
Related
Right now I have a few layers to my project: Core <> Repository <> API... and I'll be building a "client" MVC web project layer. My question is - where do viewModels belong in this architecture?
Should the controller methods of the Web Project call the API (multiple times - getTheseObjects, getThoseObjects) to get data, and then build the viewModel? Or should the API support calls to construct the viewModel so that only one API call (getAllObjectsForThisPage) needs to be made per page for the application?
Your view models will belong in your client MVC app. They will be specific to the views in that individual client application, and usually will get populated by domain objects.
This is how it can work: the controller mediates the https requests thus calls a API endpoint and receives some data or domain objects, which in turn you use to populate your view models.
Take a look at automapper if you are returning domain objects from your api, it really helps with mapping domain object to view models.
You can place ViewModels into your MVC application, but you could create something that is called DTO (Data Transformation Object) and return that from Web API to your client. In essence it will be a class with only the necessary information that you pass to the client. If you want to call that ViewModel you might as well go ahead and call it like that. My suggestion would be to issue one call and to return all the necessary information. One call one trip.
My practice usually is to separate ViewModel from MVC and store it in some other project. The service layer would prepare a ViewModel and return it to MVC. The reason for this is that once I had a requirement to build WPF application after MVC was completed. It was quite a pain moving things around and retesting everything to make sure that it still works fine.
I'm very new with breezejs and having a few questions.
I think that breezejs has very nice features so I can replace my own datacontext. However, I don't want breezejs to interact directly with the dbcontext layer. In fact, in my application, the Service layer only exposes ViewModels - not even the real Business models - to the Controllers . So i'm not so sure whether I can use Breeze or not, since in few Breeze's examples, I only saw Breeze interact directly with DBContext.
Thanks.
=========================================
Thanks Ward for the answer,
About the features that I like from Breeze is that it will help to reduce a lot of time to build my own client-side view models. And to build a SPA, maintaining client-side view models is really painful for me, especially my application have desktop app client and other hand-held device's apps as well. Also, to handle the mapping from a JSon object to Knockout - which means with each view models, I will need a mapper as well.
Currently, my architecture is like this:
Server-side:
Repository layer <=> Service layer <=> Controllers (with the Web API that exposes to Client-side)
Controllers only can get the data (in format of a View Model) by sending request through Service.
So, my question is whether it is possible to make use of Breeze to query and also its integration with knockout.
Breeze never works directly with your DbContext; it works with the service model that you expose through endpoints on your service (e.g., Web API controller methods). But you certainly get the most value from Breeze when the client can query and save entities that are structurally the same as entities on the server.
You can retrieve ViewModels with Breeze - you can call almost any HTTP service method with Breeze. It's not clear to me how Breeze would help you manage those ViewModels on the client once you had retrieved them.
What features of Breeze seem "very nice" to you? Your answer to that question will help you determine if Breeze can be helpful with your preferred architectural style.
Querying data through Breeze without API controllers using DBContext directly should be no problem, saving might be harder but still manageable. I think the most complicated part is to get metadata to the client.
According to this SO answer, samples for exposing metadata from other sources that DBContext directly should be out in a week or so.
Meanwhile, check BreezeJS spa-template sample as there is repository pattern involved on the server side which makes it similar to your data access setup.
Consider an ASP.NET MVC 2 web application project that uses EF4 POCO entities and the repository pattern to store information in a SQL Server database. So far there are 3 projects, 4 if you count the database:
1.) Domain.dll, has no dependencies, exposes POCO's and repository interfaces.
2.) Storage.dll, depends on Domain, implements repository interfaces (using EF 4).
3.) Mvc.dll, depends on both #1 and #2, provides UI layer.
4.) SQL Server database + connection, dll agnostic (no dependencies).
Let's say I add another web application to host a WCF Data Service, which provides an OData feed of the database using Domain.dll and Storage.dll:
5.) Provider.dll, depends on Domain & Storage, provides OData service layer.
Where does the domain validation logic belong in this solution? If the domain POCO classes are decorated with validation attributes, does the WCF data service need anything else to protect the data? Is it ever a good/bad idea to put validation logic into stored procedures, and why?
I would say put DataAttributes on the Domain and use the validation in MVC for the MVC part and use Ent Lib to do the validation in the WCF Service. Alternatively you could use the Ent Live validation in both MVC and WCF, but thats not what this is about. I dont know that this needs to come down to DDD semantics. MVC does validation on the Models when they have DataAttributes, so follow that and do the same in WCF.
I marked this as subjective and argumentative because even the DDD community can't make up its mind about this.
How many layers do you need to change if a new validation requirement for Customer.LastName comes in? Can the UI layer inform the user the domain, wcf, web, database layers have rejected their commands? How is a LastName restriction that a LastName can't exceed 50 characters part of the business domain?
You can see that this is really a discussion and not a answerable question.
Also if your using OData as a Database feed for your services you are not using DDD. You are using Persistance-As-Model or DDD-Lite. This is actually harmful and results in questions like this that try to resolve the problems with using two incompatible patterns together.
I have an asp.net mvc application and i need to connecto to the DB i have saw a tutorial video that connect to DB using wizard by adding DB connection and determine the DB and add a model but i need to know if i can use connection string and query the DB or calling procedures in DB ???
I need any tutorials or step by step article that describe how to connect to DB without wizard and call procedures and query tables.
Thanks in advance and i am a begineer in MVC
I hesitate to respond to this, but EVERY video you have seen is likely using an OR/M to generate the Model and the DAL. The generated DAL will likely encapsulate your calls to the stored procedures that you're asking about.
The thing is -- and here's why you're not getting the answer you're looking for -- each OR/M is going to have a different method of retrieving data from and inserting data into the database. How you retrieve data from the DB using an OR/M is going to be different if you're using Entity Framework, Linq to SQL, SubSonic, NHibernate, or any other OR/M.
So, the question is to you. Are you using a OR/M? If so, which one? If not, then you will use the standard ADO.NET calls to retrieve and store data. This is also reflected in my comment to your original question.
Yes you can (google ado.net for tutorials on ado.net), but it's not the MVC way. The MVC way is to use some sort of ORM (Object-relational mapping) such as NHibernate, Subsonic or Linq for SQL.
how to connect to DB without wizard and call procedures and query tables.
To call a procedure (here it will return no result, just perform some action):
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection .Open();
using(SqlCommand command = connection.CreateCommand(nameofthestoredprocedure))
{
command.CommandType = CommandType.StoredProcedure;
command.Parameters.AddWithValue("#someparameter", somevalue);
maCommande.ExecuteNonQuery();
}
}
You can put your connection string in the config, just like you're used to.
You can call procedures the same way you would from any .Net application too. #svinto's advice about using an ORM is another way of doing things and is well worth looking at too. Many of the good examples for ASP.Net MVC use the ORM techniques.
If you don't want to go down that route, you might benefit from creating a seperate class library project that you reference from your MVC application. Your Class Library project can act as your data access layer (DAL) where you handle db calls, etc...
Your Controllers can then call your DAL and processing methods to populate entities for the Views.
Ahmy, I think the best advice to give would be before you start off developing using the MVC framework is to have a look into the principles behind the MVC pattern and domain driven design.
Specifically , have a look at repository patterns etc.
You can still add connection strings to your web.config in a block and access them as you would have done in a webforms project, after all Asp.net MVC is based on webforms. Its just likely that you wouldn't really want to do this if you're utilising MVC the way it was intended, its all about seperation of concerns.
www.asp.net has some great intro. examples worth watching.
Try downloading NerdDinner, or even better ... ContactManager iteration 1 (the tutorial directly answers your Q). Those should give you a good idea for how to handle database access. I wouldn't suggest looking at something like Oxite or MS StoreFront though, as these are a bit more complex.
To specifically answer your question: the connection string, like in ASP.NET, can go in your web.config or hard-coded in your application.
I am starting out on a project that will involve ASP.NET MVC using a legacy ODBC 2.0 compliant database. The goal is to replace current system functionality with a web front end over a period of maybe a year then swap out the backend with SQL Server.
The plan would be to code against SQL server then insert some shim into the repository classes to use ODBC instead. Is it even feasible to do this ? Entity Framework doesn't have built in support for ODBC.
Any thoughts or advice would be appreciated.
I personally use NHibernate with MVC. Originally I picked it up because our database doesn't support EF but enjoy it enough that even if we moved to SQL Server I'd keep NHibernate.
The learning curve is kinda weird. It is definitely steep to become an expert, but it is interesting in that it is pretty organic to let it handle more and more of the work for you as you get comfortable with certain layers.
So for your case NHibernate probably supports your database, can be used as a simple data access layer (just returning DTOs), provides a database agnostic interface and can support SQL Server when the time comes. If you end up wanting more out of NHibernate it is there when the time comes.
There's nothing to stop you writing your own data access layer, to query the ODBC Database. You could also make your own entity layer so that the MVC model can populate your entities using the data layer, and return these objects to the controller.
Basically, have a data access and entities layer under your mvc app, then you can replace these entities, with entity framework, or nhibernate entities, at a later date.
This way of doing it means that your MVC app doesn't need to know what database it is using, it also means that you should have an easy time when you switch an entity later.