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.
Related
We've started considering using BreezeSharp as we have a WebAPI ODATA Service that we'd like to re-use with a ASP.NET site (no javascript involved, just pure C#).
Unfortunately, we just noticed that, according to the documentation, all of our model entities should now inherit from Breeze.Sharp.BaseEntity. That's a no go for us as this would mean having a dependency on Breeze in our business model. We'd rather keep this dependency on the WebAPI service only.
Is there anyway we could avoid this ? Having proxy classes on the client-side for instance when they don't inherit from BaseEntity ?
Any thoughts on this ?
The Breeze.Sharp.BaseEntity requirement is purely on the client side, and the reason for it is to provide all of the persistence, navigation, key-fixup, change tracking and notification and other services that make the breeze client so easy to use.
There is an IEntity interface that Breeze.Sharp.BaseEntity implements and you are free to implement it instead of using the Breeze.Sharp.BaseEntity, however, this is a very nontrivial task. We are considering offering some guidance on this at a later date if our community generally finds it desirable.
We are also planning on releasing an AOP implementation of IEntity that can be injected directly on top of POCO model objects, but this is likely to require PostSharp and may also have issues running on some client platforms (Xamarin for Android/IOS). No timeframe for this until we get a sense of the demand.
The current implementation on the other hand is very respectful of your model objects, there is only a single 'EntityAspect' property added to your model along with several events.
We have tried the pure POCO approach in the past, on numerous other platforms and application libs and have found that the disadvantages outweigh the minimal cost of a base class, especially when considering that we wanted this library to run in any .NET client including Xamarin/Mono.
If I understand correctly, your only concern is that you don't want to refer to breeze# libraries in your server model. Apparently you have no issue with close coupling of your client and server entity classes in the sense that they have identical properties and perhaps shared methods as well. I'm not being judgmental; I'm merely trying to confirm your architectural decisions.
Have you considered partial classes?
You define the partial class w/o breeze in your server-side business model project and link to that class source in your client model project ... where you keep the companion partial class with the client-specific functionality. That client partial class file specifies the breeze# base class.
While you are at it, you can segregate server-only logic in partial class files that reside in your server project but not in your client project.
Such source file linking has become even easier with VS now that Microsoft is promoting it in their vision of "Universal apps".
I've been reading various other questions about using asp.net-identity but I don't see anything concrete with regards to using it with an existing database when the project is developed in tiers. For argument's sake, say the following is true:
Solution
WebUI
Services
UserService
Data
MyDbContext
Core
User
How can I specify User (from the Core project) to be the IUserStore for the new identity provider? Am I missing something, or does this all assume that the website and the membership database always reside in the same project(or there are strict references to the Microsoft.AspNet.Identity.* libraries wherever the models reside)?
Setting up a DbContext at the WebUI layer just for authentication (and tie it in to the "MyDbContext" with a service) seems hacky. Am i missing something, or was the team just planning on this being only used in simple applications?
And feedback would be appreciated.
More Information
if it's worth mentioning:
This would be a completely new solution; I do not have old/existing aspnet_* or webpages_* tables to worry about. I'm trying to take various other custom solutions and tie them in to one solid solution, so I'm open to a lot of options. However, I would like to keep things broken out by layer (if at all possible).
Asp.net Identity Framework is set of components helping application to work with User Identity. Core framework blocks are in Microsoft.AspNet.Identity.Core assembly. The second Microsoft.AspNet.Identity.EntityFramework is the data persistence implementation for the Core framework.
Now for the n-tier application, you can define your AppUser model in any project/assembly. You need to inherit it from the Microsoft.AspNet.Identity.EntityFramework.IdentityUser. So based on your approach, you need to reference particular assembly.
Same is for the MyDbContext. You must inherit from the currently only available Persistence Microsoft.AspNet.Identity.EntityFramework.IdentityDbContext<TUser>. Your MyDbContext can be in other project/assembly. You need to refer to your AppUser assembly too in this project/assembly.
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.
I am working on an asp.net MVC 3 project as a team member. This project has some folders like repositories, infrastructure, Datalayer, services, providers and ViewModels. When I create an asp.net MVC 3 application, It has only 5 folders views, models, controllers, contents and scripts. Why these additional folders are created. I read in an article (http://msdn.microsoft.com/en-us/library/aa973811.aspx) that service is an object that performs a distinct part of the application functionality and Repositories are strongly typed classes that provide create/read/update/delete for objects. what is difference between service and repository. If I name these folders to something else will it make any difference. What type of classes should go in below folder classes:
repositories
infrastructure
Datalayer
services
providers
ViewModels
I read somewhere that repository is a pattern what does it mean? Also are services also a pattern?
Please suggest
Regards,
Asif Hameed
It is most likely something added by the software architect in your project. I would guess that Datalayer and repositories are there to help out with implementing a layered architecture. Perhaps something like:
Datalayer (NHibernate or some other ORM or whatever)
Repositories (Classes used for CRUD stuff)
Application (Your MVC application, where controllers use repositories to fetch data, then put this data in the models, then sending the models to the views where the data is displayed)
Something like this, I guess, would be a typical way to use MVC3. Hope it helped :)
Are there any best practices that cover the places that ASP.NET MVC models should be defined?
A new ASP.NET MVC project has a nice neat Models folder for them to go in, but in a production environment they can come from other places:
Third party class libraries
WCF services
Is it acceptable for a strongly-typed view to use a class defined in such a location?
In just about every project I have worked on the models of ASP.NET MVC are more View Models than models in the traditional sense of the word. I have yet to have a project where I can use the same Model that I use in my data access for my View Model. There is just too much other information that needs to be displayed on most pages. So for that reason I will either store my models in the models folder or store them in a separate library with all of my other MVC specific classes.
I don't know what you exactly mean by putting models in WCF services. If you mean using WCF services that expose the model object you need, that would work.
Regarding separate class libraries to hold your models, views and controllers, I think that's a pretty common approach and works pretty well. In fact, I believe this is really a requirement when the size and complexity of your application grows. It's a kind of physical separation of the distinct logical components in an MVC app.
One issue that I've found is that, unless the model is defined in the web project, VisualStudio seems unable to find it when using a strongly-typed view specified in markup. My models are usually defined in a separate project and I've found that to use strongly-typed views, I need to create a codebehind so that I have a class that derives from a strongly-typed ViewPage. Then I change the markup and associate it with this class.
You need to import the namespace to the view page. This does not require a codebehind page.
Use the directive
<%# import namespace='your.namespace.here' %>
immediately after the <# Page..... directive