My question is pretty simple: is it a good practice to place the .edmx file in the model folder in a Web application of an MVC3 project?
my answer is pretty simple, do not mess up presentation layer (Whole MVC application) with data access logic and data modeling.
Have at minimum 4 projects in your Visual Studio Solution, from bottom to the top:
1 - ProjectName.Interfaces (Class library, entities's interfaces);
2 - ProjectName.DAL (Class library, the only one allowed to even know the EF is used, the POCO entities implement the interfaces of project 1 using another file where you redeclare same objects using partial classes...);
3 - ProjectName.BL (Class library, Business logic, references the two projects above 1 and 2);
4 - ProjectName.Web (ASP.NET MVC application, Presentation Layer, references two projects 1 and 3 but NOT 2);
this to simplify things of course, based on my experience this is a solid design, a bit overkilling for very small projects but pays off in the long term.
in my view, the M of MVC, Model, is NOT the data model, is not the EF, is not there to do ORM bound to the specific database engine.
this answer is subjective of course and is based on my personal experience ;-)
I agree with Davide here completely I just want to add that you should also consider using the POCO templates to generate poco objects and not return entity framework objects to another layer because it then puts a dependency on the entity framework.
At some inevitable point if you don't pluck this out into a separate project, your direct data access code ends up thrown into your web code. I see it all the time (and we've all been guilty of it at some time)
I don't think this matters much.
I use CodeFirst, so my DbContext class goes to the Model folder.
Really, the EDMX is there just for the code generation, beyond that it does not do much, its not deployed/published to your server, etc. So where it stays isn't important. You could create another folder for it EDMX if you want, or put it in Model as you asked.
Related
I have separated the various layers (Class Library Projects) in my solution explorer like this:
I want to use PetaPoco micro-ORM and someone suggested me to add PetaPoco in the Repository layer. As suggested, I added PetaPoco to the Repository project and generated model from the database. Now the auto-generated POCOs reside in the Repository.
What I am not following is when I want to implement DDD, I want all the POCOs in the Model i.e, the Business Layer.
I added a WebForm for logging in the user in the WebUI layer. Now when DDD is to be used, do I need an interface in the Model? Where to write the Validate Login method?
I strongly suggest you (re-)read Eric Evans book on Domain Driven Design. Also you should watch mr. Evans's videos after the book. DDD IS NOT about repositories, databases, assemblies, or user login.
There is also the possibility that DDD is not actually what you are looking for. Seems like you are looking for a layered approach with the ui on top on some entities/app-services on top of some repos on top of the database. Depending on what you are building, this might actually be all you need.
If you want to use PetaPoco and if your "orm" generates "models" from the db, then it does not make a lot of sense to separate them in different projects. The fact that the models are generated by the orm ( and the fact that they might need to be re-generated in the future ) makes them quite coupled with the orm so moving them in a separate assembly buys you nothing.
To answer your ValidateLogin question, i would suggest moving all auth related code to an infrastructure layer that is orthogonal ( vertical ) to the other layers. App users don't necessarily need to be "entities". You might also get away with having an app-service in the model layer that handles auth, but i usually found auth to be an infrastructure concern rather than a business concern.
In the end i would suggest you get familiar with the pitfalls and strong points of such architecture and then decide if it is a good fit for what you are building. On the other hand you need to be aware that DDD is not cheap to build and (as mr Evand said) you are probably not going to get it right the first few times.
For an ASP.Net MVC 3 website, which will be a big website( 6Month/men for the FIRST version). I'm searching what is the right approach to use the power of asp.net MVC and the power of EF.
The "power" I hope I could use of EF:
POCO generation
LINQ Queries to interrogate the database
The navigation between objects parents <-> children
The lazy loading
The "power" I hope I could use with MVC(regarding data):
Data validation
?? The usage of EF object as Strong type for my view?
But I've several concern:
The "recursive" serialization which will happen if I serialize my EF (with bi-directionnal links)for JSON, how to avoid this?
I cannot put validation attribute on POCO class
So, I know that my question is a little "generic", but I can't find a good link which point me to a direction to solve all problems which comes with the combination of those two tech, do you know a website or do you have already got those kind of problems?
The usage of EF object as Strong type for my view?
No this is not a power. In most cases this is just an issue which raises both your main concerns. Use specialized model views for your views and Json handling actions and you will be fine. If you worry about conversions between model views and entities check for example AutoMapper to simplify this.
Btw. lazy loading in web application can be issue as well. You almost always know what data you need to handle current request so load them directly instead of using lazy loading.
I have a small application developed in ASP.NET 2.0 WebForms. For learning purpose, I am thinking to convert this application to MVC 3 + Entity Framework. Below is the simplest example to simulate my application. Nothing fancy.
Application Layout:
(image should read "input fields" and not "files")
Architecture:
Key points:
Methods in Service layer is using ADO.NET SqlCommand ExecuteReader method to execute stored procedures
Most of the manipulation etc. logic is done in stored procedures. Hardly any manipulation of data in Service layer
Now I want to convert this application to MVC.
Questions:
What benefit do I get (technically) if I convert this application into MVC + Entity Framework?
How do I go about it?
I have looked at some basic MVC3 tutorials but they all talk about EF code-first, which I don't think will fit in my case since I want to use the existing stored procedures. Is that correct?
Note: I want to use the existing stored procedures. Say I don't have control on DB structure changes.
Update 1:
There isn't a single inline query in my application. Even the smallest little query is a stored procedure. Tons of them.
Using SQL Server and almost nil chances of changing to any other DBS.
Update 2:
My webforms application is 99% complete and can go live anytime but due to some business hurdles it hasn't. In mean while I thought if I can convert (i.e. develop) this to MVC, I will learn plus if it works out can go live (my first MVC) instead of the webforms one.
Before answering the specific questions I'll point out that you should probably seperate the choices into 2:
Converting the presentation layer to use MVC instead of WebForms.
Converting the data layer to use EF instead of ADO.NET.
Now for your questions
Benefits of MVC include better control over HTML, better testability, etc. Benefits of EF include abstracting away DB-specific things (you could theoretically replace SQL Server with MySQL, assuming an appropriate MySQL provider), LINQ support, etc. Of course there are also costs to such a transition.
Divide and conquer. As stated earlier you don't have to do everything at once. Start with the presentation layer and convert it to MVC. Remember that you can have mixed WebForms and MVC applications so you don't have to transition all your pages at the same time. Then convert your data layer to EF. Or start in the reverse order, whatever makes sense for your project.
[Not an expert in this topic] if you rely heavily on SPs than consider traditional EF. If you have only a few SPs then you could consider code first + handling the SPs with DataSets (potentially wrapped in custom built classes) to make everything work, though that might get complicated. As before, you don't have to move to EF if the cost is too high.
What benefits do you get? It is completely wrong question. You should ask what problems do I have with current solution and how will these problems be solved by replacing data access with EF or replacing presentation layer with ASP.NET MVC?
As I understand you want to do this just for learning purpose - it has no business drive. In such case there are some points which will get you some ideas:
If you don't want to replace existing SP logic with the common EF way you will get almost none benefits and you will not learn EF. EF allows using stored procedures either for retrieving mapped entities or for loading custom classes. Mapped entities usually represent either views or tables from the database - it is not clear here if you even want to define any mapped entities. The only benefit you get when loading custom classes is automatic populating of properties from the result set. It means that you will need class for each SP result which will have properties named exactly the same as columns in result sets. SPs in EF doesn't support multiple result sets (by default) and also doesn't support automatic loading of relations.
When moving from ASP.NET Web Forms to ASP.NET MVC + Razor you can be almost sure that non of your front end code will be usable in the new solution. You will simply create new project and do you front end from scratch.
As described by #marcind these two changes are completely independent - you can do one without other.
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've just finished going through the MvcMusicStore tutorial found here. It's an excellent tutorial with working source code. One of my favorite MVC v2 tutorials so far.
That tutorial is my first introduction to using ADO.NET Entity Framework and I must admit that most of it was really quick and straight-forward. However, I am worried about maintainability. How customizable is this framework when the customer requests additional features to their site that require new fields, tables and relationships?
I am very concerned about not being able to efficiently execute customer's change orders because the Entity models are basically drag-and-drop, computer generated code. My experience with code generators is not good. What if something goes haywire in the guts of the model and I'm unable to put humpty-dumpty back together?
In the long run, I wonder if using hand typed models which human-beings can read and edit is a more efficient course than using Entity Framework.
Has anyone worked enough with entity framework to say that they are comfortable using it in a very fluid development environment?
I have been using entity framework(V1.0) for about a year in my current project. We have 100s of tables,all added to the edmx.
Problems we face (though not sure if the new entity framework resolves these issues)
When you are used to VS.net IDE, you
will be used to doing all drag/drop
operations from your IDE. The
problem is, once your edmx hosts
100s of tables,the IDE really stalls
and you would have to wait for 3-4
minutes before it becomes responsive
With so many tables ,any edits you
do on the edmx take long.
When you are going to use a version
control, comparing 10000 line XML is
quite painful. Think about merging 2
branches each having a 10000 line
edmx,the tables, new association
between tables, deleted associations
and going back and forth comparing
xmls. You would need a good xml
comparison tool if you are serious
about merging 2 big edmx files
For performance reasons we had to
make the csdl,msl and ssdl as
embedded resources
Your edmx should have to be in sync
with your DB all the time,or at
least, when you try to update the
edmx, it will try to sync and might
throw some obscure errors if they
are out of sync.
Be aware that your
entities(tables/views) should always
have a primary key, else you will
get obscure errors. See my other
question here
Things We did/I might consider in the future when using EF
Use multiple edmx by using 1 edmx
for tables logically grouped/linked
together. Be aware of the fact that
if you do this, each edmx should
live in its own namespace. If you
try to add 2 related tables(say
person & address) to 2 edmx in the
same namespace, you will get a
compiler error stating that the
foreign key relationship is already
defined. (Tip: create a folder and
create the edmx under this folder.
If you try to alter the namespace in
the edmx without having the folder,
it does not save properly the
namespace the next time you
open/edit it)
fewer tables in edmx => less heavy
container => good
fewer tables in edmx=> easier to
merge when merging 2 branches
Be aware of the fact that object
context is not thread safe
Your repository (or what ever DAO you use) should be responsible for creating and disposing the container it creates. Using DI frameworks, especially in a web app complicated things for us. Web requests are served from the threadpool and the container were not disposed properly after the web request was served as the thread itself was not disposed. The container got reused (when the thread was reused) and created a lot of concurrency issues
Don't trust your VS IDE. Get a good
XML editor and know how to edit the
edmx file (though you don't need to
edit the designer). Get your hands dirty
ALWAYS ALWAYS ALWAYS (just cannot emphasize this enough) run a
SQL profiler (and I mean each and
every step of your code) when you
execute your queries. As complex as
the query might look, you will be
surprised to find how many times you
hit the DB Example:(sorry, unable to
get code to the right format,can
someone format it ?)
var myOrders = from t in context.Table where t.CustomerID=123
select t; //above query not yet
executed
if(myOrders.Count>0)//DB query to
find count {
var firstOrder = myOrders.First()//DB query to get
first result
}
Better approach
// query materialized, just 1 hit to
DB as we are using ToList() var
myOrders = (from t in Context.tables
where t.customerID=123 select
t).ToList();
if(myOrders.Count>0)//no DB hit
{
//do something
var myOrder = myOrders[0];//no DB hit
}
Know when to use tracking and no
tracking(for read-only) and web apps
do a lot of reads than writes. Set
them properly when you initialize
your container
Did I forget compiled queries ? Look
here for more goodies
When getting 1000s of rows back from
your DB, make sure you use IQueryable and detach the
objectContext so that you don't
run out of memory
Update:
Julie Lerman address the same problem with a similar solution. Her post also points to Ward's work on dealing with huge number of tables
I'm not too familiar with Entity Framework, but I believe it simply generates an EDM file which can be hand-edited. I know I've done this quite frequently with the Linq-to-SQL DBML files that the designer generates (it's often faster to hand-edit them than use the designer for small tweaks).
You know I'd be interested if any developers can provide some insight into this.
Any Entity Framework examples seem to only consist of about ten to twenty tables, which is small scale really.
What about using the EF on a database with hundreds or even a thousand tables?
Personally, I know several developers and organisations that were burned by LINQ-to-SQL and are holding off for a year or so to see what direction EF takes.
Starting from Entity Framework 4 (with Visual Studio 2010), the generated code is outputted from T4 (Text Template Transformation Toolkit) files which you can edit so you have full control over what is generated. See Oleg Sych's blog which is a mine of information about T4. Code generation is not a problem and T4 opens so many perspectives that I can't live without anymore.
I'm currently working on a project where we use Entity Framework 4 for the data access layer, and Scrum as the agile project management method. From one sprint to another, there are several tables added, other modified, new requirements added. When you have run once into each potential EF problem (like knowing that default values from database are not persisted by default in the .edmx file, or changing a nullable column to a non-nullable and updating the designer doesn't change the mapped property state), you're good to go.
Edit: to answer your question, it's EF 4 whose code generation is based on T4 rather than T4 supporting EF. On EF 3.5 (or EF 1.0 if you prefer), you could in theory use T4 by writing them from scratch, parsing the EDMX file in the T4 code and generate your entities. It would be quite a lot of work considering all of this is already done by EF 4. Plus, Entity Framework 3.5 only supports one type of entitiy, whereas EF 4 as built in or downloadable templates for POCO entities (that don't know anything about persistence), Self-Tracking Entities...
Considering Entity Framework itself, I think it was lacking many features in its first release, and while usable, was quite frustrating to use. EF4 is much more improved. It still lacks some basic features (like enum support), but it has become my data access layer of choice now.