WHAT? HOW? WHY? WHERE? WHEN?
Where should i use the unit of work ? and why?
A unit of work lets you perform multiple actions within multiple repositories and call Save() for all of them at once, which calls SaveChanges() which will turn the unit of work into a transaction. If anything fails during your Save() call, the operation is rolled back.So use a unit of work anywhere you need to make sure something doesn't corrupt during the data transaction. Basically use a unit of work when you want to defer transactions until you have finished a set of actions.
One reason the Unit Of Work pattern can be efficient, as the paragraph states, is because it can batch several operations and reuse resources.
Using Unit of Work provides a context that can contain several operations into a single transaction that might otherwise be difficult to operate on together.
Also, not only can the Unit of Work use a single prepared statement for efficiency, but it may also be able to submit many inserts or updates to the database in a single call - if the database driver supports it - rather than executing each insert or update individually.
why code first approach
1) Less cruft, less bloat
Using an existing database to generate a .edmx model file and the associated code models results in a giant pile of auto generated code. You’re implored never to touch these generated files lest you break something, or your changes get overwritten on the next generation. The context and initializer are jammed together in this mess as well. When you need to add functionality to your generated models, like a calculated read only property, you need to extend the model class. This ends up being a requirement for almost every model and you end up with an extension for everything.]
With code first your hand coded models become your database. The exact files that you’re building are what generate the database design. There are no additional files and there is no need to create a class extension when you want to add properties or whatever else that the database doesn't need to know about. You can just add them into the same class as long as you follow the proper syntax. Heck, you can even generate a Model.edmx file to visualize your code if you want.]
2) Greater Control
When you go DB first, you’re at the mercy of what gets generated for your models for use in your application. Occasionally the naming convention is undesirable. Sometimes the relationships and associations aren't quite what you want. Other times non transient relationships with lazy loading wreak havoc on your API responses.
While there is almost always a solution for model generation problems you might run into, going code first gives you complete and fine grained control from the get go. You can control every aspect of both your code models and your database design from the comfort of your business object. You can precisely specify relationships, constraints, and associations. You can simultaneously set property character limits and database column sizes. You can specify which related collections are to be eager loaded, or not be serialized at all. In short, you are responsible for more stuff but you’re in full control of your app design.
3)Database Version Control
This is a big one. Versioning databases is hard, but with code first and code first migrations, it’s much more effective. Because your database schema is fully based on your code models, by version controlling your source code you're helping to version your database. You’re responsible for controlling your context initialization which can help you do things like seed fixed business data. You’re also responsible for creating code first migrations.
When you first enable migrations, a configuration class and an initial migration are generated. The initial migration is your current schema or your baseline v1.0. From that point on you will add migrations which are timestamped and labeled with a descriptor to help with ordering of versions. When you call add-migration from the package manager, a new migration file will be generated containing everything that has changed in your code model automatically in both an UP() and DOWN() function. The UP function applies the changes to the database, the DOWN function removes those same changes in the event you want to rollback. What’s more, you can edit these migration files to add additional changes such as new views, indexes, stored procedures, and whatever else. They will become a true versioning system for your database schema.
Wrapping Up
The speed of going the database first or model designer first route is appealing. The result of doing so is even pretty darn good. I’ll definitely still be using the database first method when time is important or when the project is a minor internal effort. For larger efforts or for long term client projects, code first provides us the control we need to create the most efficient program and also gives us the protection and consistency of a versioned controlled database while reducing bloat. There is value in each of the 4 workflows but these are 3 reasons why you might use code first design with Entity Framewor
Why use the Entity Framework?
There are a number of places where you can read an introduction to the Entity Framework, listen to a podcast about it, or watch a screen cast or video of an interview. Even with these various resources, though, there are so many different data access technologies out there that it's not uncommon for me to get the question: Why should I use the Entity Framework? Or what differentiates it from other options like just using ADO.Net SqlClient and friends, LINQ to SQL or something like nHibernate? I like the second question better, because the truth is that different problems merit different solutions. So here's just a quick take on my perspective about these:
Entity Framework vs. traditional ADO.Net
All of the standard ORM arguments apply here. The highlights are that you can write code against the Entity Framework and the system will automatically produce objects for you as well as track changes on those objects and simplify the process of updating the database. The EF can therefore replace a large chunk of code you would otherwise have to write and maintain yourself. Further, because the mapping between your objects and your database is specified declaratively instead of in code, if you need to change your database schema, you can minimize the impact on the code you have to modify in your applications--so the system provides a level of abstraction which helps isolate the app from the database. Finally, the queries and other operations you write into your code are specified in a syntax that is not specific to any particular database vendor--in ado.net prior to the EF, ado.net provided a common syntax for creating connections, executing queries and processing results, but there was no common language for the queries themselves; ado.net just passed a string from your program down to the provider without manipulating that string at all, and if you wanted to move an app from Oracle to SQL Server, you would have to change a number of the queries. With the EF, the queries are written in LINQ or Entity SQL and then translated at runtime by the providers to the particular back-end query syntax for that database.
Entity Framework vs. LINQ to SQL
The first big difference between the Entity Framework and LINQ to SQL is that the EF has a full provider model which means that as providers come online (and there are several in beta now and many which have committed to release within 3 months of the EF RTM), you will be able to use the EF against not only SQL Server and SQL CE but also Oracle, DB2, Informix, MySQL, Postgres, etc.
xt there is the fact that LINQ to SQL provides very limited mapping capabilities. For the most part L2S classes must be one-to-one with the database (with the exception of one form of inheritance where there is a single table for all of the entity types in a hierarchy and a discriminator column which indicates which type a particular row represents). In the case of the EF, there is a client-side view engine which can transform queries and updates made to the conceptual model into equivalent operations against the database. The mapping system will produce those views for a variety of transformations.
You can apply a variety of inheritance strategies: Assume you have an inheritance model with animal, dog:animal & cat:animal. You can not only do what L2S does and create a single table with all the properties from animal, dog & cat plus a column that indicates if a particular row is just a generic animal or a dog or a cat, but you can also have 3 tables where each table has all of the properties of that particular type (the dog table has not only dog-specific columns but also all the same columns as animal), or 3 tables such that the dog and cat tables have only the key plus those properties specific to their type of animal and retrieving a dog object would involve a join between the animal table and the dog table. And you can further combine these strategies so some parts of a hierarchy might live in one table and some parts in separate tables.
In addition you can do what we call "entity splitting" where a single type has properties which are drawn from two separate tables, and you can model complex types where there is a type which is nested within a larger entity and which doesn't have its own separate identity--it just groups some properties together. The best example of this is something like address where the street, city, state and zip properties go together logically, but they don't have independent identity. The address is only interesting as a set of properties that are part of a customer or whatever. As you have noticed, for v1 you can't create complex types with the designer in the EF--you have to code them by hand in the XML files.
Entity Framework vs. nHibernate
Because nHibernate is a rather full-featured ORM, the distinguishing features between the EF and it are not as large. In fact, it is certainly true that nHibernate is a more mature product and in many ways has more ORM features than the EF. The big difference between the EF and nHibernate is around the Entity Data Model (EDM) and the long-term vision for the data platform we are building around it. The EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes. This makes it easier to create a conceptual model which is how you want to think about your data and then reuse that conceptual model for a number of other services besides just building objects. Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc. Not only does this increase the value of the data model by allowing it to be reused for many parts of your overall solution, but it also allows us to invest more heavily in common tools which will streamline the development process, make developer learning apply to more scenarios, etc. So the differentiator is not that the EF supports more flexible mapping than nHibernate or something like that, it's that the EF is not just an ORM--it's the first step in a much larger vision of an entity-aware data platform.
The main reason for using entity framework (or any other Object-Relational-Mapper such as LINQ to SQL, NHIbernate etc.) is to get easier data access in your application. With EF you gain access to the power of querying through LINQ and simple updating by just assigning the new values to a .NET object, without the need to ever write any SQL code yourself.
"What is your greatest achievement?”
This is quite a common and tricky question asked in the interviews often.Many times it is found that the candidates are in a dilemma to state which achievement in order to impress the interviewer.There is a common confusion regarding which incident can the candidates make their greatest achievement till date.So your answer should be more professional oriented rather then personal.The question is basically asked to know what personal qualities were required to achieve to achieve such a great success.This will enlighten the interviewers with good qualities within you which might be they are searching for their job post.You should not relate your greatest achievement to long past.You should tell an incident from your recent past.You can mention about your academic performances or certain extra curricular activities.It will be good to relate your achievements with the recent completion of a good project and being rewarded.You should mention about an achievement that boosted you at work,an achievement that increased your self confidence and also helped others in some way.
What are your challenges?
The interviewer wants to know about a time you faced difficult circumstances and were able to address or resolve the problem satisfactorily. Choose an example that shows your creativity, professionalism and patience. “I once had a high-profile customer who threatened to cancel her contract with my company because of a late order that cost her significant revenue. Over the course of several personal meetings, I regained her trust by assuring her the problem would never happen again, significantly reduced the fees related to her contract, and personally apologized to her board members and accepted responsibility for the delay.”
Save() for all of them at once, which calls SaveChanges() which will turn the unit of work into a transaction. If anything fails during your Save() call, the operation is rolled back.So use a unit of work anywhere you need to make sure something doesn't corrupt during the data transaction. Basically use a unit of work when you want to defer transactions until you have finished a set of actions.