I'm using EF4 in model (DB First), POCO in entities, ASP.Net in UI. I have a Biz layer of course.
I need to design dynamic form generator.
I decide to create a table from forms design by users, and then update my EF model in runtime, generate POCO objects and biz logic in runtime, and then compile them in runtime.
I have problem about updating model in runtime. any help?
Thanks in advance
-Hamid
EF is not tool for your problem! EF is build around simple concept - mapping and classes are defined at design time. If you want to do anything else EF is not for you because you are going to not supposed way of using EF = no support / unexpected behavior / unexpected challenges and big increase in complexity and costs.
You need either to use direct SQL to work with your dynamically created tables or you need to spend much more time in your design phase and build meta model which will consist of set of static tables defined in design time which will be able to hold any kind of your form.
Related
I am using MVC3, ASP.NET 4.5, C#, MSSQL.
I need to create ViewModels from my Domain Model that is automatically generated by Entity Developer.
Once I create the relevant ViewModel for an entity I can comment out non required properties for a particular View.
However there is the ongoing concern that once an entity is upgraded then the ViewModel could become out of sync, and I want to minimise the risk/effort in fixing this.
Thanks in advance.
I see the same complaint endlessly about using view models. True, they can be repetitive in nature, but copy and paste works beautifully there. If you so wanted, you could even design an interface that both your model and view model must implement, which can help you keep the two in sync somewhat. However, I think you'll find that the two will diverge more than you think.
As far as validation goes, this is also a common complaint, but it's actually a symptom of bad design. Your entity class should only have validation specific to the database, which you'll find is actually pretty sparse. Entity Framework actually does a fantastic job translating most of the properties inherent limitations to the database. For example, a DateTime property's column is set as NOT NULL by default, because the C# type itself cannot be null. There's no need to add something like [Required], because the behavior is inherent.
Other types of validations such as regex are totally inappropriate for a domain model because there's no correlation to anything happening at the database level. It's entirely for the UI, and thus belongs on your view model. I think you'll find that if you evaluate all the things you're trying to validate on your domain model, you'll find most if not all should be strictly on your view model(s) instead.
I am using ASP.NET MVC5, entity framework in my web application. It is expected complex business logic so achieving separation in code based on an individual business concern is required. I am using Code First with existing database approach. I have created 3 ADO.NET Entity Data Model in design wizard. so separate dbContext with its model. My issue arise when i created 3rd dbContext which has one table share from one of the model i have created initially. the error is Metadata Exception was unhandle by user code. I believe is something to do with Meta data but not sure how to approach this problem?
what i am trying to achieve, if one webpage (one business function) to only two table, why load whole data in memory plus decoupling will improve maintainability and flexibility to extend application without disturbing existing code!
The key to using Bounded Contexts is use of
Ignore entity
modelBuilder.Ignore<MyUnNecessaryEntity>();
and/or
change the DataBAse initializer on a MINI context to none
Database.SetInitializer(new ContextInitializerNone<MyContext>());
I like teh idea of ONLY 1 context is responsible for keeping a set of tables consistent.
The other contexts can access those tables using the same POCO definitions. They can be a subset of pocs. The context is reduced and or has NO initializer.
There is a good article worth a read from Julie Lerman on MSDN on the topic of Bounded Contexts.
When using Entity Framework with Code-First, what is the best practice when calling database data?
This is my first time using Entity Framework with MVC and noticed that it automatically builds Models in my DataLayer. I also have the basic Models within my MVC UI which allow me to manipulate and display the data within my Views. I currently grab the data using my Workflow layer, and then AutoMap the Database Model to my UI Model to display the data.
Is this the best practice? Should I be using the Entity Framework Models instead of my UI Models? Or this even possible to do cleanly?
Any information on the matter would be appreciated.
It's up to you really. If you like to re-use the same EF entities for your view models as well; go ahead. Personally, I prefer not to. This is because you normally end up adding a bunch of properties to the class that have nothing to do with what's stored in the data and yes; I know you can use the NotMapped attribute like this:
[NotMapped]
public string MyExtraProperty { get; set; }
but I prefer not to. Additionally, you end up adding [Display] and other attributes to your properties and before you know it, you've got something decorated with both data specific and UI specific attributes and it can get messy if you're not careful.
So for me; I have the following:
Domain Entity
View Model
Service/Facade/Repository
Controller calls repository to get the domain entity and converts it to a view model for displaying.
I find that to be a cleaner approach, but maybe that's just me.. the most important thing is to just choose one way and stick with it for the sake of consistency and clarity of code, but either method is acceptable.. "whatever floats your boat" as they say...
The POCOs created by EF are supposed to be used as your model. The general idea is that you have EF providing access to your database. You query EF using LINQ and/or extension methods and end up with an object or collection of objects that you display on your UI by binding them in WPF. That is of course if you're using WPF as opposed to the older WinForms. I can tell you from experience that it's a very streamlined process once you become familiar with the technologies. That's how a very basic setup would work.
A more advanced way of going about it is adding architectures like Model-View-ViewModel (MVVM) and possibly the repository pattern into the mix at which point you get better separation of code and presentation at the cost of increased complexity.
I don't know what flavor of MVC you're using and how it can be made to intermingle with the above, but if you want to know more about how EF was envisioned to work you should look into the technologies I've listed above.
We run a series of reports every 6 months and store the results to tables that can be queried/viewed at any time in the future. Depending on the cycle either two or four tables will be added. They have a standard naming convention of yyyy_mmm_Table_x.
Our website is built using ASP.Net MVC2 and the database is modeled using EF4 using the standard model designer, not Code First.
I would like to be able to dynamically add the report tables to the EF4 context at runtime. I don't want to have to manually add them to the model using the designer, otherwise every reporting cycle we have to update and recompile the model just because we added the extra reports. That would be a maintenance headache when nothing else has changed.
I can get a list of the available tables simply by querying sysobjects. If I could get this list and add the tables to the context when the site started up then I could use something like the Dynamic LINQ library to query against them depending on which table the user selected from a dropdown.
I can't use EF4's Code First out of the box because that would force me to create concrete classes for the tables and that would just be the same maintenance headache. I suspect I could use the same strategies the Code First framework uses to dynamically update the context, but I haven't looked at this library at all and I'm hoping someone familiar with it can point me in the right direction.
Otherwise I think I would have to drop back to ADO.Net to handle this area. That may be the best and simple way so I guess I'm looking for comments. I'm not a zealot so I don't need everything to be in LINQ and EF4. :) But it would seem to be a little cleaner and consistent, especially if it allows me to make use of Dynamic LINQ. But sometimes the old way is just simpler.
So, if you have any suggestions or comments I would love to hear them.
Thanks!
Even with common EF you still need new data type for each table because when you map the table you need new ObjectSet of new entity type to be able to run queries. As I know it is not possible to map two tables to the same entity even if table structure is absolutely same.
All runtime mapping is stored in MetadataWorkspace prepared by EntityConnection. So if you want to play with it you can start there but public interfaces of these classes don't look promising.
I guess you want to run Linq-to-entities on these tables so using Stored procedure returning data from correct table based on data parameter is probably not an option.
You should use common ADO.NET for this.
Having used all of them (some more than others), I am still undecided on which could be the best to use (with .NET 3.5). What are the pro's and con's of each when developing?
SubSonic 3
Not enough samples/documentation (I know its a wiki and people can update it, but it can be tricky to track things down - e.g. where are the sample apps (WebForms, MVC (current version, rather than pre-3), WinForms)). Text Templates didn't work as expected when I first tried them. For example, it does not clean up the table names like SubSonic 2 did (removing/replacing spaces for example). Also, you cannot say which tables to include, just the ones you can exclude (in ActiveRecord.tt). Context.tt and Structs.tt generates code for all the tables (you would probably not want the 'aspnet_' ones, and probably some others (session tables) as well).
Saying that though (hope I'm not being too harsh), it is quite a good ORM to use, minor issues aside.
Entity Data Model (Entity Framework)
Visual Designer for setting up models. Syncs with database, might be considered a bit 'verbose' and hard to understand. There is fairly decent documentation though. Not gone that much further in depth though.
LINQ to SQL
Also has a designer for creating models. Simple to use. Less features than the other two. I also had to apply a hotfix for an obscure bug (wouldn't update when the model had foreign keys that were not of type int)
NHibernate
Looked at this in the past, but not that easy to set up compared to the above.
Any sample ASP.NET MVC apps using this?
Ideally I would want a framework that:
a) could generate the models from a database
b) support LINQ syntax
c) retrieve only the data that is needed (e.g. for paging)
d) allow data annotations
e) could generate the sql to update or create new tables in an existing database
MVC is presentation layer, ORM is Data layer
I don't think that ORM has anything so much to do with an MVC application. At least if you tier your application properly. Model in an MVC application is rather model of the presentation layer view. A view model through which controller and view communicate. Not necessarily data model. MVC project template is a bit confusing, since developers think that MVC model = data model. In any business application that is not completely trivial (like a single assembly simple application) this is not equal. And it's better that its not. Especially if we take into cosideration separation of concerns. We shouldn't rely on particular ORM classes in any layer other than data layer.
But if you intend to use DTOs in your MVC application (as view models) I suggest you use that ORM that creates partial classes, so you can easily add additional stuff on them (like attributes). Your data annotations can be written inside of a special metadata class that can be attached to your model class by a single class-level attribute.
Suggestion
But I suggest doing something else. Use a separate layer with POCOs that will be used on all layers and would have data annotations on them. This will make your presentation layer independent of data layer and your POCOs may also be presentation optimised (like having a class called UserRegistration for instance with two password properties - with repeated value as well). Your repository in your data layer would be responsible for POCO conversion so all layers will exchange data using POCOs only instead of using data objects.
ORMs and class generation
With Entity Framework you do get a very controllable environment to generate your classes from a data store schema. Unfortunately it's not the same with others. Generateion is not all-in, but can be controlled and manipulated manually as well (if you'd like to do TPH/TPT structures).
Similar with LINQ to SQL. I haven't used any other ORM but I guess LinqConnect may have it's own editor similar to EF Visual Studio editor, because I've been working with MySql connector from the same company and I've used their designer for entities because it was better than the one provided with Visual Studio 2008.
But you have tools that provide code generation (and you can get templates on the internet for various ORMs as well):
there's T4 built into Visual Studio that can generate code for you; You can as well fint templates for ORMs written in T4 that you can then easily customize. Or write your own acording to your needs (I've written enumeration generator from DB lookup tables in the past)
MyGeneration is open source and you can find lots of templates for it
CodeSmith is not free but is a proved product that I've used in the past with .netTiers template (before we had LINQ) which saved lots of time and worked perfectly