I am building a web application which will have a public facing piece with a forms login, and an internal piece with windows authentication login. The two projects will be using the same database. I would like to rely on Visual Studio tooling as much as possible, but do things the right way.
I was thinking of creating three projects in a single solution:
Internal - ASP.Net MVC 4 Intranet application
External - ASP.Net MVC 4 Internet application
Models - just a class library
What is the best way to handle membership and database context? Move everything to the models class?
For your database access, you may be best placed to put all that configuration and your POCO classes (classes that represent your database tables) inside a Data project.
You could then put your Business logic and any other utilities inside a Core layer, this is what your Web will use to talk to the database (Core references Data).
Now, the structure of the Web side should probably just be one MVC project, you could separate both the Intranet and Extranet/External to be different Areas in that project.
To summarise:
YourApp.Data - Contains Database Configuration, POCO classes that correspond to Database tables. Also contains database CRUD methods.
YourApp.Core - References Data, wraps calls to the CRUD methods in Data inside appropriate Business Logic/Validation/Exception Handling etc.
YourApp.Web - References Core, makes call to Core methods to perform CRUD operations. Contains two Areas -> External and Intranet for each parts of your application.
Related
Is it possible to add EF6 to a razor class library ? The goal is to have many components shared by other BLAZOR projects, but a lot of these controls require access to the database, which is the same for all the projects inside this solution. Also, I assume that the db access will be via a controller since it is not possible to inject as a service. Is this correct ?
Is it possible to add EF6 to a razor class library ?
Yes but you would immediately restrict that library ro Blazor Server side.
a lot of these controls require access to the database
That is not a great architecture
I assume that the db access will be via a controller
Not necessary with server-side, you can inject a DbContext into your pages and components
When you have components that depend strongly on your Entity classes and business logic then a Razor Class Library is maybe not the best choice.
When you do want this, create a specific layer with storage-agnostic models and interfaces for services. It's the 2 layers at the core in the Onion architecture.
Your component can depend on the interfaces and the main app can implement them.
I have used MVC thus far in a traditional EF sense by creating POCO first objects and then adding this to a database context but I have a new problem in that I am trying to recreate a legacy system but using the MVC framework but it uses a connection to multiple different databases and tables.
In the legacy solution they use Enterprise library to create the link to databases but I am not sure that this is the best option available and was wondering what are the options open for dbconext in regards to different database connections at the same time, is this possible?
The question is nothing to do with MVC. Besides, ASP.Net MVC (Presentation Layer) should not even need to know about what kind of ORM or database at Data Access Layer.
Back to original question, it is not worth using Entity Framework, if you have to query two databases at the same time.
I suggest you want to look at other ORM like Dapper.
I'm new to ASP.NET MVC and inherited a project that uses the technology.
Such Web project contains three folders: Views, Controllers and Model. As I understand it, the Model contains in fact your domain / business logic and is called by your controllers. The controllers themselves act as delegators between Views and Model.
Now, in a typical layered architecture, there should be no references in any project to the Web/UI project.
I find this quite confusing:
-> The UI contains the Model, which is - in an ideal world - based on "Domain Driven Design"-principles.
-> The layers on top of the UI (Services and DataAccess) cannot have a reference to the UI
How can you write efficient services and dataaccess layers if they do not know your model?
What am I missing here? Is the Web.Model different from "DDD" and should I still have a separate BL project? If that is the case, then what is the Web.Model supposed to contain?
I view the Model as a concept. You can have a completely separate project containing your Domain (your entities, your services etc.) and reference that in your "UI" project. In this scenario this will be your "Model".
This is what I typically do, In my Models folder I keep "ViewModels", which I use for Binding/Validation (for the UI).
For example, If I have an Employee but I don't necessary want to use all its properties (or for that matter different properties), I will create an EmployeeViewModel adjust it the way I want, I'll add validation (if required) and I'll pass it to my View.
This is by no means, "the right way"/"only way", but It worked for me in the past, and I thought I'll share (also, I'm pretty terrible in explanations, so I really hope this post makes sense, in case it doesn't or clarifications are needed - please let me know).
You necessarily do not need to have your model in the same project. You can ofcourse have those in different layers.
This is how i usually setup my projects
1) UI Project - This is an MVC Web application type project where i will have my controllers and it's views and other UI related stuff
2) Business Entities - This will be a class library type project where i will define my domain objects ( Ex : Customer). This mostly looks similar to how my DB schema looks like. These are usually just POCO's which represent my domain modal ( I use this for the CodeFirst Database generation).
3) Data Access - This will be another class library type project which has the data access classes. Usually my repository class/interfaces, my DBContext class and other data access classes will be in this project.
4) Tests - Unit tests for the project
Business Entities project has been added as a reference to the Data Access Project so that i can use those classes in my Data access code.
Business Entities and Data Access Projects are added as references in UI Project. I would call the data access methods from my Controllers/ Service classes.
You may also add a Service/Business logic layer between your controller's and Data access layer as needed.
I have few ViewModel classes also inside my UI project ViewModels folder. I use this for some screens where i have to show data from multiple domain objects. I have a mapping/service class which maps the domain object to view model object. If your project is bifg, you may keep this as a serperate project under the same solution
Views Contain your HTML Layouts
Controllers do the heavy lifting of getting data from the models or the models themselves and passing them to the Views.
Models are used to do actions for your BL or fetch data.
Tip : You can use a EntityFramework ( i'm recommending it because it's easy to get started with ) to fetch your data and it's dead simple to setup thus eliminating your DAL and saving you time from writing everything yourself.
Services : you can have controllers that return XML/JSON (other format?) by converting the data you have got from the DB to XML/JSON and returning that instead of a view.
Take a look at MVC 4 WebApi for more details,Note that you can pretty much the same thing with mvc 3 too
Also refer to asp.net/mvc site for tutorials to get you started, they are really useful.
I know this has been sort of answered in various posts, but using VS2012 with MVC4, I wonder if there is a more updated method or new ways to do things.
I have a large enterprise application that has 22 projects in it. It has a complex large business object/logic project and has multiple presentation layers. Working on a new presentation layer using MVC 4. I have never used MVC before at this scale.
Here are my questions:
How do people handle the model in this scenario? All the Microsoft examples are so simple.
I have seen posts to auto mappers and recommend deves use simple models and extract from the BO layer, but some of these tools like auto mapper seem to have gone idle, is there a library in MVC that does that now?
I'm just trying to figure out best practices before I get started, seems usually I figure them out after the fact.
I break my MVC apps into several different projects.
AppName.Configuration: to handle any configuration of the app (i.e. pulling in web.config/app settings, etc)
AppName.Data: this is the data layer where all DB access is performed (no business logic). The DBML/EDMX lives here, my repository class(es) live here as well.
AppName.Models: this is where all of my ViewModels are defined for MVC, as well as other model objects needed throughout the application.
AppName.Services: This is my business layer, all everything must pass through here to get to the data layer or to the presentation layer. ViewModels are constructed from the database objects, data validation happens here, etc.
AppName.Web: this would be the MVC application.
AppName.Data.Test: Unit tests for Data app
AppName.Services.Test: Unit tests for the services
AppName.Web.Test: Unit tests for the MVC controllers
AppName.Web.UI.Test: Unit tests for the web user interfaces (using WATIN)
I don't use any auto-mappers, as i clearly define a specific viewmodel for each view of the application. If it isn't needed for the view, it doesn't go in there.
Most MVC examples are so basic, they show everything in the web app (data, models, business logic in the controllers, etc.)
I hope this helps.
So I have a DataEntity class generated by EntityFramework4 for my sqlexpress08 database. This data context is exposed via a WCF Data Service/Odata to silverlight and win forms clients.
Should the data entities + edmx file (generated by EF4) go in a separate class library?
The problem here then is I would specify data annotations for a few entities and then some of them would require specific MVC attributes (like CompareAttribute) so the class library would also reference mvc dlls. There also happen to be entity users which will be encapsulated or wrapped into an IIdentity in the website. So its pretty tied to the mvc website. Or Should it maybe go in a Base folder in the mvc project itself?
Mostly the website is data driven around the database, like approve users, change global settings etc. The real business happens in the silverlight and win forms apps.
Im using mvc3 rc2 with Razor.
Thanks
Should the data entities + edmx file (generated by EF4) go in a separate class library?
IMHO all data access logic which is specific to some data access technology (in your case Entity Framework) should go into a separate assembly. There should be no MVC specific assemblies referenced there.
In your ASP.NET MVC application you would then reference this assembly and write view models. It is those view models that will contain any MVC specific attributes. Then you could map between your model classes and those view models which would be passed to the view. AutoMapper could be used to facilitate this task.