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.
Related
I've read the MVC5 with EF6 DB First tutorial. With this tutorial, it will generate code (controller and view).
I have created 3 projects in VS:
+ AdminWebSite
+ PublicWebSite
+ EntityFramework
And I've question, where should I implement the business logic, and share it will multiple website (Admin & Public)?
The business logic may include:
Logic with database (i.e. Transaction with multi-table)
Logic with SharePoint info
Logic with Email Server
EDIT
Typo, should be 3 projects instead of 3 solution, but it should be similar case, which AdminWebSite and PublicWebSite have add EntityFramework as reference.
EDIT 2
Before the MVC3, I will create a class project which includes all business logic, and also the Repository class. So that every WebSite or WebServices can use the same business logic (but I'm not sure is it the best practice).
But when move to MVC5 with EF6, the repository and unit of work seems gone. And don't want to implement repository for every table, which some tables just for direct CRUD without business logic.
I hope this can clarify the is Too broad.
Have a look in to this:
http://dombrovsky.github.io/EntityHooks/
It looks like a framework that is designed to work with EF6. It should allow you to write custom business logic when a certain event occurs like when a record is inserted, or updated.
You can utilize Projects under a solution.
I usually have the database layer in a separate project (Class library/DLL) and let other projects refer to it. This way you have only one copy of the ORM (Entity Framework) simplifying any changes in the database model. I also create a database project (if SQL server) that holds the actual schema definitions including tables and stored procedures. This is a great way to make changes in the schema and deploying it.
Anytime a significant enough portion of the code can be re-used it is usually a good idea to make it a class library and have client projects refer to it.
One solution include Web project 、BLL project 、 DAL project，web project contains publish and admin
I would not have a project named EntityFramework, I would suggest that you replace this project with a project named Infrastructure. This infrastructure project would contain classes that depends on external sources like EmailSenders and DAL classes like EntityFramework classes and other stuff that you for some reason in the future might want to replace with other external services.
Your business logic should be stored in a Core project. This core project would not reference either the web projects or the infrastructure project (but the web projects would reference both the infrastructure as well as the core project). If you need an EmailSender in the core project you reference an interface like IEmailSender, which is located in core as well.
This is basically the structure I would suggest:
AdminWebSite
PublicWebSite
Infrastructure
EF
Log
Messages
SharePoint
Core
Test (This project contains all your unit and integration tests)
I really suggest that you read up on using Dependency injection. When you understand DI, the separation of core and infrastructure will make sense and you see how these can use each other without any hard references.
If you dont want to use UoW or Repositories, I would suggest that you move EF to core but the infrastructure project is still very much valid for other external services.
Since I am new to MVC I have a few questions about the database connection.
I am trying to build an MVC application, and so far I have built 2 layers: Model(where my classes are, without any functionality) and Business (there is the functionality for my classes, every class has its own Business class) and there is also my MVC application. Both these layers are separated from the MVC project, I use them as ".dll-s". I am also using the repository pattern and the dependency injection is done by Unity.
Now comes the tricky part (or at least it is for me). I want to bind my application to a database. Most of the tutorials I have found rely on Entity Framework, but I don't want to use it, I want to use ADO.NET (Entity Framework makes me feel like I am giving my "power" away, so I want to manage the SQL on my own). So what is the best way to do it? How can I access the Web.Config from outside and read the connection string (or should I take care of the connection string inside the data access layer)? Is there any best practice how to manage the connection from "outside"? I mean I could easily just create a dbaccess object inside my MVC application, but I don't want that. In the MVC application I just want to use my business(object) classes.
And one more thing. What is the best practice for DataAccess: to build a new layer, or is it also fine to include the functionality inside my business layer? I am more tending to build a third layer, so I can reuse this code for any other application but maybe there are some other approaches.
You can create another project called "DAL" to handle your data access layer which is built using pure ADO.NET. You will add a reference to the entity project so that you can return these entities from your Data access methods. Now from your Business Layer, Add reference to the Data Access projects so that you can access these data access methods from the Business layer classes. From your MVC project, Add reference to your Business project ( and entities project if you are using those entity objects in your MVC project). In this way your MVC project do not have any idea what data access technology you are using.
You do not need to have connection string in your DAL project, Keep that in your UI MVC project and your DAL project will be able to read it as long as you have the proper references added between these projects.
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.
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.
I have the following task:
I have to create the following: Domain Logic, Data Access Layer, Database.
I will also have to create an ASP.Net Page to work with the aforementioned pieces (ASP.Net is only part of the system, there may be a desktop app etc).
I want to use the Entity Framework as the Data Access Layer, but here is my confusion:
I dont know how I should go about creating the different layers... I cant work out what project type they would be..I would usually use the ADO.Net Entity Framework within a C# Windows Form project with a SQL Database. However, the fact that I will have ASP.Net and Windows Forms possibly using the domain logic confuses me as to how and where I would place each part? The Domain logic, the DAL and the Database..? Also, how would I interact with each layer? Any help would be GREATLY appreciated as I have no clue how to go about this currently.. I hope I explained this reasonably, Thank you.
I would create separate projects for each, i.e:
Library project that houses the models
Another library project for business/domain logics
Web project (ASP.NET / MVC)
With that setup, you can reuse your library projects in WinForm, WPF, etc... project by just referencing the libraries.