I have a project called MyApp.DataAccess which contains several database contexts. This started as one context and has grown to three (all separate databases required for my app). As you can imagine I have Initializer classes for each as well and I'm also now trying to use Migrations. I can see that this will really clutter up my MyApp.DataAccess project.
I also have a project called MyApp.Model which contains model classes which are generally organized in folders per their use in each aforementioned Context.
I'm struggling with how best to organize multiple DbContexts and Model classes.
My instinct tells me option 1 but what is the best practice?
Create a MyApp.DataAccess.[ContextName] project for each DbContext which contains the DbContext, migrations, and relevant Model classes. Ultimately I'll still need a MyApp.Model project to represent non-database Model classes.
Create a MyApp.DataAccess.[ContextName] project for each DbContext which contains ONLY the DbContext and Migrations; continue to use the MyApp.Model for ALL model classes (organized in folders and sub-namespaces).
Do nothing -- a single MyApp.DataAccess with multiple DbContexts, multiple migrations, etc.; a single MyApp.Model with Models for multiple databases organized by folder.
What is the best practice / ideal approach?
Your question should start with "why should I have different DbContexts". In most cases different contexts mean different data models, different - unrelated - responsibilities, and thus should be as well separated as that's possible. Which means that different assemblies are go.
Related
We are starting to develop a new asp.net mvc 5 application that should be multilingual.
I found a very nice tutorial how to get this working. The only thing I wonder about this tutorial is, that the author suggests to create a separate project inside the solution for the resources.
Now my question: Is this recommended?
I usually create a folder called Resources inside my MVC project. Although if you wish to reference your resources from other projects, you may wish to create them inside a separate project.
I then sub-folder based on my controller names and change the 'Custom Tool' property to 'PublicResXFileCodeGenerator'.
When I use the resource strings in my Views, it looks like:
<title>#Resources.Home.Index.PageTitle</title>
Personally, I prefer to use a folder rather than a project, as this forces me to not generate UI strings in my application layers and forces me to find better ways to solve problems where I might end up generating strings in my business logic that might end up in the UI.
We have resource files in projects where they are most relevant.
We have a component that handles the translation of resources on different levels
( also for Winforms and WPF...)
and we group resource files according to functional importance,
bussiness level messages in a project for the Bussiness layer,
a project for common translations used by our standard code.
A .NET ResourceManager can handle one resource file, so our manager keeps a list of ResourceManagers.
At runtime you just try them all ( or work with logical category names to speed up the lookup)...
I am new to ASP.Net MVC. I have a couple of controllers and models. They all use a set of static functions and constants which I call common code.
In my MVC project I have folders for Controller, models and view etc,
Where is all the common code supposed to be put ?
Is is OK to create a Common folder and create new class for my static functions and same for global constants ?
If you reuse this common code often across solutions, you might want to consider compiling it into its own class library and simply referencing the assembly.
Another thing you'll want to consider is the nature of the common functions. Are they truly just helper functions (like manipulating strings and stuff like that) or do they make more sense mixed into your business layers?
Basic rule is to keep it organized be consistent. There's no right or wrong way to structure your application...only hundreds of thousands of opinions.
Exactly you can create Helper folder when you set your extension methods or another common utility.
But for constants suggest you to create Ressource File
Remarks : All text , warning or info messages, put theses elements in ressource and don't write in code, for gloabalization need(It's my case on project)
When migrating an Entity Framework 5.0 based project from code-first to database-first. We'll be using the standard VS2012 wizard to generate the edmx models off the database but do we have any additional steps beyond that? I presume I'd have to delete all classes where I've defined the code-first models and even the migrations folder - any other cleanup operations beyond those two?
[Edit]:
Reporting back.
So the actual experience was between my original expectations and what Ladislav mentioned (like he said, exact conditions are code dependant). For me the entire operation took about 15-20 minutes mostly involving
Branch creation (safety, in case stuff blows up!)
Removal of Code-first classes and source (I moved them outside VS2012 for a diff reference)
Creation of the EDMX model from the database (passing same namespace etc to the wizard to reduce the extent of differences)
Quick inspection of the code-first classes and the auto-generated db-first classes. This was mostly 1:1 since we used sensible names in the code first model to begin with.
Compiling and fixing each error one by one
Noticed many errors were due to automatic pluralization of EF 5 vs my own pluralization of different fields. Fixed 40+ errors via a quick case sensitive search-> replace all
Rerun all the tests after compiling
Merge feature branch back in!
Thanks
This may be quite complex if your entity or context classes contains any additional logic. You must:
Add EDMX model to your project and let it generate entity classes and context class
Remove migrations
If your original context class contains any additional code you must convert it to partial class with the same name, namespace and assembly as newly generated context class with only that additional code.
If any of your entity classes contained any additional code you must follow the same procedure as with the context.
If the additional code was actually called from inside of the code which is now auto generated you must make some other changes which may include changing code generation template and using partial methods.
You must remove any database initialization or migration execution from your bootstrapper
You must use the new connection string referencing metadata files
Another more complex option is not using auto generation feature and use your old context and entity classes but in such case you will have to keep them in sync with your EDMX manually.
We're currently migrating our ASP Intranet to .NET and we started to develop this Intranet in one ASP.NET website. This, however, raised some problems regarding Visual Studio (performance, compile-time, ...).
Because our Intranet basically exists of modules, we want to seperate our project in subprojects in Visual Studio (each module is a subproject).
This raises also some problems because the modules have references to each other.
Module X uses Module Y and vice versa... (circular dependencies).
What's the best way to develop such an Intranet?
I'll will give an example because it's difficult to explain.
We have a module to maintain our employees. Each employee has different documents (a contract, documents created by the employee, ...).
All documents inside our Intranet our maintained by a document module.
The employee-module needs to reference the document-module.
What if in the future I need to reference the employee-module in the document-module?
What's the best way to solve this?
It sounds to me like you have two problems.
First you need to break the business orientated functionality of the system down into cohesive parts; in terms of Object Orientated design there's a few principles which you should be using to guide your thinking:
Common Reuse Principle
Common Closure Principle
The idea is that things which are closely related, to the extent that 'if one needs to be changed, they all are likely to need to be changed'.
Single Responsibility Principle
Don't try to have a component do to much.
I think you also need to look at you dependency structure more closely - as soon as you start getting circular references it's probably a sign that you haven't broken the various "things" apart correctly. Maybe you need to understand the problem domain more? It's a common problem - well, not so much a problem as simply a part of designing complex systems.
Once you get this sorted out it will make the second part much easier: system architecture and design.
Luckily there's already a lot of existing material on plugins, try searching by tag, e.g:
https://stackoverflow.com/questions/tagged/plugins+.net
https://stackoverflow.com/questions/tagged/plugins+architecture
Edit:
Assets is defined in a different module than employees. But the Assets-class defines a property 'AssignedTo' which is of the type 'Employee'. I've been breaking my head how to disconnect these two
There two parts to this, and you might want to look at using both:
Using a Common Layer containing simple data structures that all parts of the system can share.
Using Interfaces.
Common Layer / POCO's
POCO stands for "Plain Old CLR Objects", the idea is that POCO's are a simple data structures that you can use for exchanging information between layers - or in your case between modules that need to remain loosely Coupled. POCO's don't contain any business logic. Treat them like you'd treat the String or DateTime types.
So rather than referencing each other, the Asset and Employee classes reference the POCO's.
The idea is to define these in a common assembly that the rest of your application / modules can reference. The assembly which defines these needs to be devoid of unwanted dependencies - which should be easy enough.
Interfaces
This is pretty much the same, but instead of referring to a concrete object (like a POCO) you refer to an interface. These interfaces would be defined in a similar fashion to the POCO's described above (common assembly, no dependencies).
You'd then use a Factory to go and load up the concrete object at runtime. This is basically Dependency Inversion.
So rather than referencing each other, the Asset and Employee classes reference the interfaces, and concrete implementations are instantiated at runtime.
This article might be of assistance for both of the options above: An Introduction to Dependency Inversion
Edit:
I've got the following method GetAsset( int assetID ); In this method, the property asset.AssignedTo (type IAssignable) is filled in. How can I assign this properly?
This depends on where the logic sits, and how you want to architect things.
If you have a Business Logic (BL) Layer - which is mainly a comprehensive Domain Model (DM) (of which both Asset and Employee were members), then it's likely Assets and Members would know about each other, and when you did a call to populate the Asset you'd probably get the appropriate Employee data as well. In this case the BL / DM is asking for the data - not isolated Asset and Member classes.
In this case your "modules" would be another layer that was built on top of the BL / DM described above.
I variation on this is that inside GetAsset() you only get asset data, and atsome point after that you get the employee data separately. No matter how loosely you couple things there is going to have to be some point at which you define the connection between Asset and Employee, even if it's just in data.
This suggests some sort of Register Pattern, a place where "connections" are defined, and anytime you deal with a type which is 'IAssignable' you know you need to check the register for any possible assignments.
I would look into creating interfaces for your plug-ins that way you will be able to add new modules, and as long as they follow the interface specifications your projects will be able to call them without explicitly knowing anything about them.
We use this to create plug-ins for our application. Each plugin in encapsulated in user control that implements a specific interface, then we add new modules whenever we want, and because they are user controls we can store the path to the control in the database, and use load control to load them, and we use the interface to manipulate them, the page that loads them doesn't need to know anything about what they do.
I'm creating a data model first using the LINQ-To-SQL graphical designer by using right-click->Add->Class. My idea is that I'll set up everything first using test repositories, design the entire website, then as a final step, create a database using the LINQ-To-SQL classes as a model for the database tables and relationships. My reasoning is that it's easy to edit the classes, but hard to modify DB tables (especially if there's already data in them), so by doing the database part last, it becomes much easier to design the structure.
My question is, is there an automatic way to link the two once I have the DB tables created? I know you can manually fill out the class properties for the LINQ-To-SQL entities but this is pretty cumbersome if you have a lot of tables to deal with. The other option is to delete your manually-created classes and drag the tables from the database into the designer to auto-generate the classes, but I'm not sure if this is the best way of doing it.
Linq to Sql is intended to be a relatively thin ORM layer over a database. While you can of course just add properties to a data context and use them as a sort of mock, you are correct, it isn't really easy to work with.
Instead of relying solely on Linq to Sql generated classes to give you freedom from the database implementation, you may want to look into the repository design pattern. It allows you to have a smooth separation between your database, domain model, and your middle tier; I have used it on two projects now, and have been able to (for the most part) build everything top-down, leaving the actual database for last. Below is a link to a good tutorial on the pattern (better than I could scribble down here).
https://web.archive.org/web/20110503184234/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx
Depending on your database permissions, you may call your datacontext's DeleteDatabase() and CreateDatabase() methods as a ungraceful way of resyncing your classes and tables. This is not much of an option when you have actual data in the database, but does work when you are in your development stages.
Take a look at my add-in (which you can download from http://www.huagati.com/dbmltools/ , free 45-day trial licenses are also available from the same site).
It can generate SQL-DDL diff scripts with the SQL-DDL statements for updating your database with only the portions that has changed in the L2S model (e.g. add missing columns, missing tables, missing FKs etc), instead of the L2S-out-of-the-box support for recreating the entire db from scratch.
It also supports syncing the other way; updating the model from the database.