I need to create composite key with fluent API dynamically according to database schema.
I google for the solution but can't find any.
Any suggestion how to do that?
Evolving database = evolving classes = evolving mapping. There is no automation for this because your classes don't have to be 1:1 image of your database and it is up to mapping to describe how they relate.
Even doing 1:1 automation is project itself. It is quite complex task and it will take you much longer to built that then simply evolving your mapping manually. Also there is no reason to do that because it already exists in EF Power Tools.
If you still want to do that go to SQL Books online and learn how SQL persists information about tables, columns, relations, constraints, etc. Then learn how to either use T4 templates or CodeDom to generate classes. Use these two set of information to get description of database and create mapping accordingly (it will be much harder if you would like to do that mapping to existing classes btw.).
Related
I have a core data schema file with relationships between the entities.
I need to create a SQL database and would like to know if it can be created automatically (MySql or MS-SQL) using only this file.
Looking at the SQLite DB I see that the relationships are not mapped in any logical way.
First, your assessment that the relationships are "not mapped in any logical way" is not correct. If you look carefully at the Core Data generated database you will discover that the relationships are mapped exactly as in any other old relational database scheme, i.e. with foreign keys referring to rows in other tables.
Also, the naming conventions in these SQLite databases are very transparent (e.g., entity and attribute names start with Z, etc.
That being said, I would strongly discourage you to hack the Core Data generated database file, or even to use it to inform another database scheme, the reason being that these are undocumented features that could change any time without notice and thus break any code you write based on them.
IMO, the most practical thing to do is to rewrite the model quickly in the usual MySQL schema format and update it manually as well when you change the managed object model.
If you would like to automate the process, there is a rich set of APIs provided for interpreting and parsing NSManagedObjectModel, including classes like NSEntityDescription, NSAttributeDescription etc. You could write a framework that iterates though your entities and attributes and generates a text file that is a readable schema for MySQL, complete with information about indexing, versions etc..
If you go down that route, please make sure to notify us and do post your framework on Github for the benefit of others.
If you use Core Data you can create an SQL based database using a schema file but its structure is entirely controlled by the Core Data framework. Apple specifically tell us as developers to leave it alone and do not edit it using libsqlite or any other method. If you do then Core Data won't have anything to do with you!
In terms of making your own DB using one of Apple's schema files, I'm sure it is possible, but you'd have to know the inner workings of the Core Data framework to even attempt it.
In terms of making your own SQLite DB then you have to sort out all the relationships and mapping yourself.
I think that mixing and matching Core Data resources and custom built SQLite databases is probably a headache waiting to happen. I have used both methods and find that Core Data is brilliant (especially with iCloud) as long as you're OK with your App being limited to Apple only.
I was watching some videos and tutorials for EF 4.1, and I do not understand any benefit of CodeFirst (except some if DB is very small 3-4 tables and I am lazy for creating DB first).
Mostly, the best approach so far is to create Database in some sort of Database editor, which is sure faster then editing in the Entity Model and EF picks up every relationships and creates associations correctly. I know there are challenges in naming convention etc, but I feel its very confusing to manage Code First as everything looks like code and its too much to code either.
What is it that CodeFirst can do and Db first cannot?
CodeFirst cannot do anything that DB first cannot. At the end of the day they are both using the Entity Framework.
The main advantages of using codefirst are:
Development Speed - You do not have to worry about creating a DB you just start coding. Good for developers coming from a programming background without much DBA experience. It also has automatic database updates so whenever you model changes the DB is also automatically updated.
POCOs - The code is a lot cleaner you do not end up with loads of auto-generated code. You have full control of each of your classes.
Simple - you do not have a edmx model to update or maintain
For more info see Code-first vs Model/Database-first
and here Code-First or Database-First, how to choose?
Coming from a DataCentric approach, I will always find it strange the people like to create in a Code First Approach. When I design my database, I am already thinking about what each of the tables are as if they were classes anyway. How they link together and how the data will flow. I can image the whole system through the database.
I have always been taught that you work from the ground up, get your foundations right and everything else will follow. I create lots and lots of different systems for lots of different companies and the speed that I do it is based on the fact that once I have got a strong database model, I then run my custom code generator that creates the Views/Stored Procedures as well as my Controller/BusinessLayer/DataLayer for me, Put all of these together and all I have to do is create the front end.
If I had to create the whole system in code first to generate the database, as well as all of the other items then I would image it taking a lot longer. I am not saying that I am right in any terms, and I am sure that there are probably faster and more experienced ways of developing systems, but so far, I haven't found one.
Thanks for letting me speak and I hope my views have helped a little.
Migration was enabled in EntityFramework 4.3 for CodeFirst , so
you can easily update changes from model to the database seamlessly Reference 1
detailed video:Complete Reference Video
Well, it depends on your project. I'll try to make a synthase some ideas:
You have total control on the entity classes. They are no more generated, you don’t have to update T4 templates or use partial classes…
EDMX model will disappear in EF7 in favor of CodeFirst model. So keep in mind if you plan to migrate to EF or you have projects start in the near future that could use EF7.
Easier to do merge in case multiple devs are working on the model
+/- Annotations and mapping should be done manually. I would say code first approach seems lighter (less bloat) and we can keep things simple (visual model could hide undesired complexity). Open to Fluent API.
You can still visualize model via Power Tools, but the model is read-only. Any change to the model should be done manually (even the initial entities can be generated from scratch). You don’t have partial models (diagrams), but our models should be small enough.
It seems database first is better integrated with SPs and function results (some improvements have been done in EF6)
First a background. Our application is built on ASP.NET MVC3, .NET 4.0, and uses Linq-to-Sql (PLINQO) as its primary means of data access. Our web application is a multi-tenant/multi-client system where each client gets their own Sql Server database. Each Sql Server database up to now has had exactly the same schema.
Often times, clients will ask us to track custom fields in their Db that other clients don't track. The way we've handled this is by reserving a number of customfields in the db in our main tables. For example, our Widget table may have a CustomText1, CustomText2.. CustomText10, and a CustomDate1, CustomDate2..CustomDate10 fields. Again, all our schemas across clients are the same, so Linq-to-Sql handles these fields just as easily as any other field.
Now we are running into an issue where a client wants several hundred CustomBool fields, but doesn't need the others. So, basically, we are researching for ways to still use the Linq-to-Sql, but have it work against potentially different schemas depending on the database it is connected to (although they are different in a very specific way.)
Too much code has already been built on Linq-to-Sql and accessing the Widget classes generated by it that I'd like to not just fall back to straight SQL.
I've seen answers here and on the web on ways for Linq to Sql to access different tables that have the same schema, but I have not found a good answer to the same table name across different dbs with different columns.
Is this possible?
If the main objective is to store a few extra fields for existing domain objects then why not create a generic table that can store key value pairs. This is extremely flexible since there is no need to change your schema if a customer requires a new property.
We do this frequently and normally have some helpers to correctly cast the properties e.g.
Service.GetProperty<bool>("SomeCustomProperty")
If you are looking for a more "pluggable" domain model that can be completely different for each tenant, I think you will struggle if you are following a database driven approach and using the L2S designer to generate your code.
To achieve this you really need to be generating your database based on your code (domain driven design) which will give you much more flexibility i.e. you can load a tenant specific configuration (set of classes, business rules etc.) at runtime and use this to generate/validate your schema.
Update
It would be good if you could elaborate on exactly what design approach you have taken i.e. are you using the Linq designer and generating your model from the database?
It's clear that a generic key value pair store is not going to meet your querying requirements.
It's hard to provide a solution without suggesting a different technology. Relational SQL databases aren't really suited for dynamic domain models. You may be better off with a document database such as MongoDb or RavenDb where you are not tied to a specific schema. You could even make use of these just for your custom properties.
If that's not ideal then another solution would be to use something like Dapper to construct your queries. Assuming you are developing against interfaces you can have a implementation of your data service per tenant that makes use of their custom fields.
Ayende did a whole series of posts on Multitenancy and covers tenant specific domain models. It starts here and may be of some use to you.
I am currently reading Pro Asp.Net MVC, and they are building all of their linq2sql entity classes by hand, and mapping them with the linq mapping attributes. However, everyone else I see (from google searches) talking about linq 2 sql seem to be using the visual designer for building all of their entities. Which is the preferred way to build l2s entities, and what are the advantages/disadvantages of each?
The only difference I have noticed so far, is I can't seem to do inheritance mapping when using the visual designer, although MSDN says I should be able to so I might just be missing it in VS 2010's interface. However, I'm not so sure I should use inheritance anyway as that could technically add additional joins when I don't need the sub table data.
As a PS, l2s will not be doing any modification of my schema, I will be generating schema changes manually and then replicating them in linq2sql.
Thanks,
We used the designer all the time. It indeed introduces an added step, every time you make a change to the schema you need to import the table into the designer again, but I think that effrot pales in comparison to the amount of code you need to write if you bypass the desginer.
Also note that the designer creates partial classes, you can create an additional file for the partial class that includes additional implementation details. That way, when the table gets refereshed in the designer, it leaves you additional code alone. We do this to add a lot of helper functions to the classes, and also to provide strictly typed enumerated properties that overlay the primitive integer FK fields.
It's true that inheritance would be very difficult to accomplish well, but I think if you need that sort of data layer, L2S may not be the best solution. I prefer to keep my data layer clean and simple, just using L2S to get the data in and out, and then pu more complicated logic in the business layer. If we really needed to do things like object inheritance in our data layer, I would probably explore a more advanced and complicated technology like EF
We've built our entire application framework backend using L2S. I developed most of the this. I started to use the DBML designer but I quickly realized this was a royal pain. Every schema change required a change to the table(s) in the designers. Plus, the entities created by the designer all get stuffed in a single class file, and didn't have all the functionality I wanted, like support for M2M relationships, and more. So, it didn't take long before I realized I wanted a better way.
I ended up writing my own code generator that generates the L2S entities the way I want them, and it also generates a "lightweight" set of entities that are used in the application layer. These don't have any L2S plumbing. The code generator creates all these entities, and other code, directly from a target database. No more DBML!
This has worked very well for us and our entities are exactly the way we want them, and generated automatically each time our database schema changes.
First a bit about the environment:
We use a program called Clearview to manage service relationships with our customers, including call center and field service work. In order to better support clients and our field technicians we also developed a web site to provide access to the service records in Clearview and reporting. Over time our need to customize the behavior and add new features led to more and more things being tied to this website and it's database.
At this point we're dealing with things like a Company being defined partly in the Clearview database and partly in the website database. For good measure we're also starting to tie the scripting for our phone system into the same website, which will require talking to the phone system's own database as well.
All of this is set up and working... BUT we don't have a good data layer to work with it all. We moved to Linq to SQL and now have two DBMLs that we can use, along with some custom classes I wrote before I'd ever heard of Linq, along with some of the old style ADO datasets. So yeah, basically things are a mess.
What I want is a data layer that provides a single front end for our applications, and on the back end manages everything into the correct database.
I had heard something about Entity Framework allowing classes to be built from multiple sources, but it turns out there can only be one database. So the question is, how could I proceed with this?
I'm currently thinking of getting the Linq To SQL classes all set for each database, then manually writing Linq compatible front ends that tie those together. Seems like a lot of work, and given Linq's limitations (such as not being able to refresh) I'm not sure it's a good idea.
Could I do something with Entity Framework that would turn out better? Should I look into another tool? Am I crazy?
The Entity Framework does give a certain measure of database independence, insofar as you can build an entity model from one database, and then connect it to a different database by using a different entity connect string. However, as you say, it's still just one database, and, moreover, it's limited to databases which support the Entity Framework. Many do, but not all of them. You could use multiple entity models within a single application in order to combine multiple databases using the Entity Framework. There is some information on this on the ADO.NET team blog. However, the Entity Framework support for doing this is, at best, in an early stage.
My approach to this problem is to abstract my use of the Entity Framework behind the Repository pattern. The most immediate benefit of this, for me, is to make unit testing very simple; instead of trying to mock my Entity model, I simply substitute a mock repository which returns IQueryables. But the same pattern is also really good for combining multiple data sources, or data sources for which there is no Entity Framework provider, such as a non-data-services-aware Web service.
So I'm not going to say, "Don't use the Entity Framework." I like it, and use it, myself. In view of recent news from Microsoft, I believe it is a better choice than LINQ to SQL. But it will not, by itself, solve the problem you describe. Use the Repository pattern.
if you want to use tools like Linq2SQl or EF and don't want to have to manage multiple DBMLS (or whaetever its called in EF or other tools), you could create views in your website database, that reference back to the ClearView or Phone system's DB.
This allows you to decouple your web site from their database structure. I believe Linq2Sql and EF can use a view as the source for an Entity. If they can't look at nHibernate.
This will also let you have composite entities that are pulled from the various data sources. There are some limitations updating views in SQL Server; however, you can define your own Instead of trigger(s) on the view which can then do the actual insert update delete statements.
L2S works with views, perfectly, in my project. You only need to make a small trick:
1. Add a secondary DB table to the current DB as a view.
2. In Designer, add a primary key attribute to a id field on the view.
3. Only now, add an association to whatever other table you want in the original DB.
Now, you might see the view available for the navigation.