first of all
i am planning to my project.So, i am just making research.
now
i have a project that contains data access layer.
to build that layer, i know this solutions:
creating a stored procedures and call it from my code. This way is very old.
working with linq with sql. I read that this way will be die soon.
working with entity framework. i tested it and make a small test project. it seems that it contains all what i need.
my project should give a web services.
I make a research about web services and I found that RESTFUL web service is suitable to my need.
my question
what is the best way to create web servcies on a project that its access layer is entity framework
I would recommend using .NET Web API.
You can read more about it here: http://www.asp.net/web-api
Just add a new Web API project, which communicates with your data-access layer, and you're good to go!
The easiest way would be to use WCF Data Services. This makes it easy to expose an Entity Framework model using the OData protocol, which uses the semantics of REST.
See also http://msdn.microsoft.com/en-us/library/cc668792(v=vs.110).aspx for more about WCF Data Services. This requires .NET 4.0 or 4.5.
Related
I'm developing a web application that is going to use WCF as a buisness logic provider.
My solution consists of these 4 projects:
- ASP.NET MVC project
- UnitTests project
- ProjectCore - C# library with code first entity framework database
- WCF Service Application
My question is related to the WCF service and database model location.
Which option should I use (and why):
- Move code first EF db to WCF service application project?
- Add WCF service to ProjectCore?
- Leave it as it is in different projects?
I have maintained one big project where all WCF services were included in one Core library and it worked well but I wonder what you may suggest.
Practically it would work everywhere, but the right approach is a DAL(Data Access Layer) project.
So add another project containing your DAL objects and methods. This might seem a little unnecessary for an EntityFramework connected db, but for other type of more complex connectors(where you need to right your own queries) DAL is a life saver layer. Hence it's a good practice to get used to it.
I'm just trying to wrap my head around this concept. I have written a couple different Web APIs but they have always been consumed by a website and interacted via JSON. I have a question about how to structure the implementation when the Web API will be consumed by a windows service.
In this case there is already an existing Database so I want to use Entity Framework's Database First approach.
I create a Class Library project for the models and use Entity Framework to look at the existing database and generate all of the required classes.
Then I create a Web API Project and add my Class Library with all of the models to it. Up to this point I am good.
My question is when I go to build the Windows Service that will interact with the Web API, how do I access the classes from my Class Library model project? I know I could add that project to my windows service but that doesn't seem like the correct approach because that would pretty much by-pass the Web API.
I guess my question is if I want to create and pass an Employee object to my Web API (so it can insert it into the database) from my windows Service, how does the windows service get the Employee object without adding the Class Library to the Windows service project?
In an n-tier solution you don't pass domain objects across physical boundaries, but you implement data-transfer objects (DTO) that will only hold the required info by the consumer/caller.
Usually you're going to created a shared library that will have the whole data-transfer objects and this will be referenced both by the server and the client.
After that, it's all about using a JSON serializer in order to serialize and/or deserialize your data-transfer objects.
Domain objects will be always mapped to data-transfer objects because these are lighter than a full object. Make yourself a question: if the consumer only requires the name and the second name of someone, why you need to send more data over the wire?
In addition, it's important to avoid server dependencies in client applications and services.
Some useful tips:
Learn what's a DTO: http://en.wikipedia.org/wiki/Data_transfer_object and http://martinfowler.com/eaaCatalog/dataTransferObject.html
Check AutoMapper and how can save you time in order to map domain objects to data-transfer objects: http://automapper.org/
Normally you create exra model classes that are used for the Web API. Those model classes often contain only a subset of the data of the entities. Furthermore, this distinction allows you to create truly RESTful APIs.
Inside your Web APIs controller classes the mapping between Model and Entity happens.
The windows service only referenes the project with the Model classes but not that with the Entity classes.
I have a strange situation. I have created a data model visually and generated a database from it. This project is referenced by two projects:
ASP .NET application.
WinForms application.
The ASP .NET application deals directly with the database while I need the WinForms application to interact with the database via the Web application.
I have created a page called API.aspx and use HTTP POST to send values and get results in XML.
However, since the WinForms application still needs to use the data model classes, I am running into issues using them without creating a database object.
What is a good strategy to use in this scenario?
If you have implemented your code with loose coupling (See the Repository Pattern), then you could create a database stub that will return dummy data (or in memory data) until you are ready to plug in the actual EF framework.
This is generally good practice to create a clean separation of concerns.
This sounds like a candidate for an SOA implementation, rather than having the windows forms app communicate directly with the web application:
http://en.wikipedia.org/wiki/Service-oriented_architecture
http://msdn.microsoft.com/en-us/library/aa480021.aspx
I'm totally rewriting the question..
I'm new to ASP.Net, and trying to develop a website that is
- simple, but has many grids
- uesrs will update/delete/insert data on grids/tables through the website
Other facts would be:
- MS SQL Server 2008
- .Net Framework 4.0
- intranet
- thin client
- the website should be secure - no hole for sql injection etc.
- 10 users
- Database tables are already defined
- no stored procedures are defined yet, but will be soon
- all database related functions will be done through stored procedures.
Can you please suggest which approach would be the best in my situation to communicate with the database securely. Entity Framework? LinqToSQL?, WCF? or ASP.Net Web Service?
I was thinking of Entity Framework as suggested below, but here are more questions related to EF:
1. Do I need WCF for EF?
2. if DB tables are already structured, do I need to rebuild DB tables along with EF?
3. is EF has more secure than ASP.Net Web Service?
4. Functions are fully done by stored procedures, EF is a good choice?
Why would you use a webservice?
You can check just communicate with the database through Enterprise Library, LINQ2SQL or Entity Framework
As architecture, I understand MVC, MVC2 or MVC3 frameworks that you can use to build your application.
As grids you may use MSSQL-side query paging or client side jQuery Datatables paging..
Entity Framework would be a great choice for this. You don't need any web services. EF 4 has a great thing called Code First, but in your case, your tables are done and I wouldn't suggest it. My recommendation would be for you would be to use N-Tier architecture to design your site. Using N-Tier will maintain a separation of your data layer, business rules and your UI. Your data layer should be a separate class project that should only be accessed by your business rule layer. Your UI should never communicate with the data layer and only communicate with your business rule layer. If you want to go even further, program your site to an interface using something like IoC and Ninject. This will ensure a true separation of data and UI.
Maybe the simpliest way is to use ASP.NET Dynamic Data
I recently started learning about ASP.Net MVC and its various features MVC_3_MUSIC_STORE +
CODE .
It looks very structured and simple to understand.
I was reading about enterprise applications and how they are layered/tiered in different sections
(logical/physical)
I was wondering(for learning ) how to do separate(convert) the above MVC_3_MUSIC_STORE into n-tier or 3 tier application (since we already have a working example) in order to have a clean separation of concerns.
I don't have much prior experience in this.
What changes would be required?
What will be different DTO(s) or POCO(s) that would be needed?
The above example uses POCO entities around from controller to views.
Would it remain same, assuming EF Code first is used.
Also i was wondering what changes will be required if WCF Webservice is introduced as a data access layer. i.e.Instead of retrieving data from DAL ,Clients will request data to and from WCF Webservice. Client can be Web app or WinForms or Sliverlight app.
( [DAL <--> WCF WS] <--> N CLIENTS)
Would be interesting to know about various approaches.
Example code would be helpful and/or examples for same.
Edit 1 - Added
One of the things I noticed was when i move the model classes from Model folder to new project "MYMODEL" I will have to again add reference to "System.ComponentModel.DataAnnotations" and "System.Web.Mvc" in new model project?
How can this be avoided? How can these validations be moved to Business layer?
Edit 2
Looking for something similar to this
Advice For A Newbie About N-Tier Applications
Normally the only change that will be required is that you will provide an implementation of the repository (DAL layer) which will call a WCF web service to fetch the domain models from instead of some EF DataContext talking directly to the database. A change completely transparent to Controllers and Views.