In my project many tables are linked to aspnet_Application table by ApplicationId foreign key. I don't want the users to view or edit it, so I'm looking for way to preset this sql table field value before the insert query is executed. I still have scaffolding enabled for this column (in order for DD to generate the right sql script) but I'm hiding this column/field in all my edit/list/insert pages.
Ideally I'm looking for a place to inject my code right before DynamicInsert is executed for any table in my LinqToSql class.
Thanks
So after some digging around I came up with an acceptable solution. I've created a partial class for my data context and added a partial Insert_ method for every table that's linked to the aspnet_Applications. In every method I set the ApplicationId field to current application id.
It looks like this:
public partial class MyDataContext
{
partial void InsertMyTable(MyTable instance)
{
instance.ApplicationId = HttpContext.Current.Session["ApplicationId"] as Guid?;
this.ExecuteDynamicInsert(instance);
}
}
Note that you can't execute other LINQ statements while in this method. In particular I had to store the application id in session rather than querying the aspnet_Applications table.
While this is acceptable solution it isn't perfect (a lot of repetitive code) so if anyone knows better throw me a bone here :)
In the future the best solution would be to use DomainService part of .Net RIA Services preview just released at MIX09 see there videos here:
.NET RIA Services - Building Data-Driven Applications with Microsoft Silverlight and Microsoft ASP.NET
Microsoft ASP.NET 4.0 Data Access: Patterns for Success with Web Forms
The first is an introl to .net RIA Services from the point of view od Silverlight but more of it applied to DD the second is David Ebbo's presentation at MIX and shows how DomainService works with DD I think this is the way forward as you can do all your business logic here in the DomainService.
Related
Background
With ef core code first approach, validation is robust and simple: https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-mvc-app/validation
With the database first approach, it seems like any validation is happening behind the scenes by the database when dbcontext.SaveChanges(); is called. What's worse, these exceptions are nebulous and entirely unhelpful, for example, SqlException: String or binary data would be truncated can be thrown if any of the string properties of any of the entities have too many chars (ours is a legacy app riddled with char(10) and such), or even if a key that is a string is left null.
Question
I want to know if there is any reasonable or accepted way of enforcing the validation. I've found this question which might help debugging, but I would like to enforce the constraints in code
Is there any better method than changing every auto property to one that throws if it's constraints aren't met?
EntityFramework Core does not enforce any validation at all. The validation rules you see in the example are enforced by MVC and not EF. One of the main reason for EF Core to remove validation check was that only. Validation are run in UI and then in EF and then again in database which is just redundant. Hence client side validation is left to the front-end (MVC in this case) and server side is done by database engine.
When you use database first approach, EF core does not generate any annotation for validation because it does not reason about them anyway. That means you would get only server side validation which means error during SaveChanges.
The only way to enforce constraint in the code (client side) is to write those annotations so that MVC can enforce them or write custom code to deal with it. The whole validation mechanism is transparent to EF.
I ended up going with a psuedo extension to the generator tooling. Since the DBContext is a partial class, I made a new class that has a main
public partial class DBContext{
public static void Main(string[]args){
DBContext context = new DBContext();
var modelbuilder = new Microsoft.EntityFrameworkCore.ModelBuilder(new Microsoft.EntityFrameworkCore.Metadata.Conventions.ConventionSet());
context.OnModelCreating(modelbuilder);
IMutableModel model=modelbuilder.Model;
from there I used Linq to transform the various info about each entity's properties and the annotations on them into List<KeyValuePair<string,List<KeyValuePair<Regex,string>>>> where the first pair's key is the entity name, and the value is a list of find and replace pairs to edit the code that had already been generated with the corresponding validation, one per property. Then all I had to do was abuse the fact that the tooling generates the classes in <className>.cs files, and iterate over my list, executing the replacements for each entity source code file.
I'd have preferred doing something a little less hacky, because I'm relying on format that the ef tooling outputs, but it works
I am a newbiew to aspn.et.My requirement is to create a simple class and web form. the data submitted to the form should be stored in object of the class and then it should be saved in the sql server database.Same way the retireval. thanks.
class Student
{
int rollno;String name;int age;//default getters and settters
}
//web form has 3 text boxes for the above data fields.
//DB has a single table with these 3 fields
You can try the tutorials on asp.net, which covers pretty much all of the web technologies used/integrated with Visual Studio product. Here is the link to the WebForms with Entity Framework that will walk you through how to do it.
http://www.asp.net/web-forms/tutorials/data-access/model-binding/retrieving-data
edit: Database first method -> http://www.asp.net/web-forms/tutorials/getting-started-with-ef/the-entity-framework-and-aspnet-getting-started-part-1
Additionally, if that tutorial doesn't suit your fancy, try this search: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=web-forms+database+first
From a couple of articles I have found online
http://typecastexception.com/post/2013/10/27/Configuring-Db-Connection-and-Code-First-Migration-for-Identity-Accounts-in-ASPNET-MVC-5-and-Visual-Studio-2013.aspx
http://www.codeproject.com/Articles/790720/ASP-NET-Identity-Customizing-Users-and-Roles
I have seen it is very simple to extend the ApplicationUser class in MVC 5/Identity 2.0. It basically requires adding of property to that class and all dependent views/viewmodels etc to implement the new functionality. The only question I have remaining is due to the fact that these articles all give you examples in regards to a code first perspective. How would extending the Applicationser class work with a database first perspective?
Here is what I imagine.
1.) Change the connection string to your production database. (In my case SQL Azure)
2.) Create the tables that are normally automatically created by identity 2.0 in SQL Azure.
3.) Fill those tables with the default properties and types.
4.) Add custom properties to the AspNetUsers table. (E.G. City, Zip, etc)
5.) Add those properties to the actual ApplicationUser class
6.) Update dependent views, controllers, viewmodels etc.
Is there a more simple way in doing this?
No, there is no other way to extend ApplicationUser. Code-First is pretty much the same, only adding properties first, create migration, run migration, update your controllers/views.
I am trying to use Entity Framework 4.0 for an asp .net application. As of now, it will be old style code behind files and without unit testing but in the future I may use MVP and unit testing but as of now, it is not a concern for me. I am using Database First approach. Here is a model ( I could not post image as I need reputation to post image)
Table: Application (ApplicationID, Name, Hidden)
Table: User (UserID, ApplicationID, Username, IsActive)
Table: Role (RoleID, ApplicationID, Name)
Table: UserRole (UserRoleID, RoleID, UserID)
I have been reading a lot about Entity Framework and how to use it but still could not get a very basic idea about some stuff. Where do I write a code like this for Application, User, Role, UserRole etc?
public List<Application> GetAllUnhiddenApplications()
{
List<Application> applist = null;
using (CustomAppsPortalEntities ctx = new CustomAppsPortalEntities())
{
applist = (from app in ctx.Applications
where app.Hidden == false
orderby app.Name
select app).ToList();
}
return applist;
}
I have separated Context and Entities in separate projects Project.Data and Project.Entities respectively. My question is if above code belongs to BLL (class name ApplicationBLL) or DLL (ApplicationDLL)? From past 2 days, I have been searching lots of SO questions, blogs, tutorials and different people have different approach. Here is my dilemma.
If I put the code in Data layer, then in the business layer, I have to create a "pass through" function like ApplicationBLL.GetAllUnhiddenApplications which will return ApplidationDLL.GetAllUnhiddenApplications. I have to repeat it for all the queries and basically whole BLL will eventually become "pass through" layer for DLL. Can you give me a concrete example of what Business layer will be used for in reference to above schema?
If I put the code in Business layer, then linq will exist in Business layer which eventually will be converted to SQL by Entity Framework so it is like exposing query logic to Business Layer.
Our Environment
Our environment is fast paced and want to complete this project as soon as possible with the moderately proper approach where there is a separate layer but in the future when we find time, we may refactor the code and make it really robust but it is not a concern as of now but if the time permits, we want to implement best practices right now versus refactoring code in the future.
The above code would typically be in the BL layer. Using linq in your BL layer is fine because your linq queries are still data persistence ignorant. From linq queries perspective, it's querying objects from entity framework.
What you might be missing is a "repository pattern" and "unit of work patter". The repository pattern acts as an interface to entity framework. It allows you to interact with EF objects like in-memory collections. Typically I keep all repositories in one project and reference accordingly. To give you an example, Microsoft Spain provides a n-tierd example,
http://microsoftnlayerapp.codeplex.com/
It's very over engineered, but I believe it will give you what your looking for.
Many people argue that EF IS the DLL.
Typically, I set my projects up something like this...
D ---> Presentation Layers (MVC, WCF, WinForms, etc)
A |
T V
A ---> Business Logic Layer
|
M V
O ---> Entity Layer / DLL
D
E
L
The Data Models project is really just a collection of POCO's that can be used in any of the other projects.
The Entity Layer is your EDMX file and Context.
It should be fine to access the context in the Entity/DLL layer, since .Net has abstracted everything out for you.
If you think about it, the whole reason to abstract out a DLL layer is so that you can change databases without having to change the BLL. With EF, you can change a database in 1 step and everything should still work.... as long as your schema stays the same.
Mates, I want to update a role description using my application
I don´t know what is the better way to connect to the database and run a UPDATE statement.
Would it be Entity Framework? LINQ? None of this 2 options..
Please, suggestions.
I would say that Entity Framework would be currently the best solution for you. Not only it is strongly supported by Microsoft (well Silverlight was as well) but:
If you start with it, you can use designer. It's graphical UI will guide you when generating the model (based on database) or generating the database schema when starting with model.
Read some tutorials abut it:
http://msdn.microsoft.com/en-us/data/ee712907
And later take a look how to use some more profesionla techniques as Repository pattern or unit of work
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
Not Linq ..well yes linq, but linq is the querying framework where as entity framework is the object relational mapper. So Both actually. You could do this in various other ways but those two technologies work very well together from my experience.
In Visual studio you would create a new ADO.NET project template which you then hook up to your database. and then you can update the tables and do a whole bunch of stuff. Linq is build into .NET so technically you can query any objects using linq ( which makes it so much fun ) and because your entity is an object you just reference it ( first declare it ) and then play with it
FooModel foo = new FooModel(); // Entity
var fooQuery = from _ in foo.DescriptionTable // Linq query
where _.Description == SelectedDesc // table selection query
select _;
foo.Add(fooQuery); // add to database
foo.SaveChanges(); // save changes
Something like that. There is a bit more to it that would project specific but you would have to give more details.
It is most certainly worth learning both technologies and have doubt you will find them very useful. Both can get very complex but for what you need it for you just need the basics down and then you can explore from there.