Note: This is a follow-up question for this previous question of mine.
Inspired by this blog post, I'm trying to construct a fluent way to test my EF4 Code-Only mappings. However, I'm stuck almost instantly...
To be able to implement this, I also need to implement the CheckProperty method, and I'm quite unsure on how to save the parameters in the PersistenceSpecification class, and how to use them in VerifyTheMappings.
Also, I'd like to write tests for this class, but I'm not at all sure on how to accomplish that. What do I test? And how?
Any help is appreciated.
Update: I've taken a look at the implementation in Fluent NHibernate's source code, and it seems like it would be quite easy to just take the source and adapt it to Entity Framework. However, I can't find anything about modifying and using parts of the source in the BSD licence. Would copy-pasting their code into my project, and changing whatever I want to suit my needs, be legal for non-commercial private or open source projects? Would it be for commercial projects?
I was going to suggest looking at how FluentNH does this, until I got to your update. Anyway, you're already investigating that approach.
As to the portion of your question regarding the BSD license, I'd say the relevant part of the license is this: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [conditions follow].
From my reading of that line, you can modify (which would include the removal of any code not relevant to your use cases) the code however you wish, and redistribute it as long as you meet the author's conditions.
Since there are no qualifications on how you may use or redistribute the code or binaries, then you are free to do that however you wish, for any and all applications.
Here and here are descriptions of the license in layman's terms.
I'm always writing simple set of integration tests for each entity. Tests are persisting, selecting, updating and deleting entity. I thing there is no better and easier way to test your mapping and other features of the model (like cascade deletes).
My problem is a simple one. I've created a class library for Delphi 2007 and added the modelling support to it that Delphi offers. It generates nice class overviews of my code, which I'd like to use. But it's not enough. I want to export the generated UML to Altova's UModel to generate some additional documentation and nicer-looking models.
I can't find a way to export the UML from Delphi, though. I can't even find anything in Delphi that would help me to generate any other documentation, except for the class model images that it allows me to save.
My main problem with my class library is that while it's usage is simple, it's creation was quite complex. I've used several techniques to encapsulate functionality, types within types, interfaces and delegations, type aliases and a lot more. The result is actually three simple-looking classes that only expose methods needed to call a specific web service with one class for the WS itself, one class to manage the input and one to manage the output. The class interface is thus kept simple to make it's usage simple. Unfortunately, the complexity of the WS required me to create some complex code.
I need to generate two kinds of documentation now for this code. One simple document that explains how it's used. That one is simple. A second one that explains how to maintain the code, what is where and how and why certain decisions have been taken. That one is complex and requires me to model the whole thing.
I have UModel, which is a great product, especially with C# and Java code. Unfortunately, it can't import Delphi code. I've tried Enterprise Architect, which can manage Delphi code, but this code happens to be way too complex. EA doesn't understand a thing about types within types and other features I've used. Also tried StarUML but had to cry after 10 minutes of usage since that product is just real bad... And doesn't even support Delphi... My hard disk feels real dirty now after I've installed it...
And while I could continue to try other modelling tools, I think I should have a better chance in findiing some way to convert the Together UML stuff to a regular XMI file.
You might want to try ModelMaker.
It has an add-on that allows you to export the UML as XMI, which you can import in Altova UModel.
ModelMaker supports both the Delphi and C# language.
--jeroen
I'm afraid there's no such thing as "regular XMI file" (see for instance this example, that shows the differences in the XMI representation of the same model depending on the tool you use).
I am planning to build a web application using ASP MVC3 that runs on Azure with a SQL Azure back end. I would like to use the Microsoft stack and have no plans to ever change to another stack. I am looking into the use of WCF and WF but that would be in the future.
I looked at the traditional and Code First approach to using Entity Framework but I can't see if there is any advantage in using one or the other approach. Sure they each have advantages but for me I don't care if my classes do inherit from EF classes. All I want is to find the most efficient solution.
Can anyone out there give me some advice as to which approach might be the best.
thanks very much
Richard
This is really more of an opinion gathering question and probably belongs more to the Programmers site of StackExchange, but I'll take a stab:
I am definitely a traditional approach kind-of-a-guy. To me, data is key. It is most important. Various objects, layers, applications, services come, go and evolve. But data lingers on. Which is why I design my databases first. In my experiences, data has always been king.
I'd go with Code First approach.
This great blog post by Scott Guthrie explains its advantages.
Code first for me also. If you suddenly started to hate Entity Framework and wanted to switch to NHibernate you will have a lot less work on your hands.
Also, there is a cleaner separation of concerns by totally isolating your domain layer from your data access layer.
I am not 100% sure it still applies, but I think the code generation, partial class malarky of entity framework can cause problems when testing.
Did I mention code first is a lot less hassle.
Code First is an "Architecturally correct" approach, but reality tends to differ on these things when you have to consider effort, value, and speed of developement.
Using the "Model First" approach is much faster and easier to maintain. Database changes propagate with a simple right click "Regen from database", you don't get strange errors creeping into your code when you forget to change a property name or type.
Having said that you can have a bit of both with the the new POCO support in EF4. You can remove the dependencies on base classes while at the same time use the modelling tools:
A lot of good links in this thread:
Entity Framework 4 / POCO - Where to start?
I have existing java code and need to create Design Document based on that.
For starter even if I could get all functions with input / output parameters that will help in overall proces.
Note: There is not commeted documentation on any procedures, function or classes.
Last but not least. Let me know for any good tool which will reduce time required for this phase. As currently we write every flow and related stuffs.
What you want is just too much. Quoting Linus Torvalds: “Good code is its own best documentation.”. Anyway, I digress.
You might want to look into UML tools which generate class/sequence diagrams from the code. There are many of them but only a handful support reverse engineering (into and from the class diagram), and even fewer subset support the same to/from sequence diagram. I only know MagicDraw could do this, but I am biased as I used to work for the manufacturer of this tool so do your shopping around first.
Use java docs: http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
or Introspection: http://docs.oracle.com/javase/tutorial/reflect/class/classMembers.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have read a lot of articles on Dependency Injection as well as watched a lot of videos, but I still can't get my head around it. Does anyone have a good analogy to explain it?
I watched the first part of the Autumn of Agile screencast and still was a little confused.
Analogy? I'll give it a whack... Your CD Player stereo is useless without a CD with music on it... (It's dependent on the CD). If they built CD Players with the CD already in it, it would get boring very quickly...
So they build them so you can "inject" the CD, (on which it is dependent) into the player. That way you can inject a different one each time, and get "different" behavior (music) dependent on which one you inject.
The only requirement is that the CD must be compatible with the interface defined by the player. (You can't play a blue-ray disk in a 1992 CD player.)
The best analogy I can think of is that of hiring a mechanic.
Without dependency injection, you hire a mechanic and the mechanic brings his own tools. He may have lousy tools, he may have great tools, he may be using a pipe wrench when he should be using a socket. You don't know, and may not care, so long as he gets the work done.
With dependency injection, you hire a mechanic and you provide him with the tools that you want him to do his work with. You get to choose what you consider to be the best or most appropriate tools for the work you are hiring him to do.
Think of it as a realisation of the "Inversion of Control" pattern. I guess, your problem is, you are so used to it, you don't realize it's that simple.
Let's start at the beginning.
In the early days programs followed a given path through the code. The order of the called functions was given by the programmer.
In interactive programs, e.g. mostly ANY program, you can not say, which function is called at what time. Just look at a GUI or website. You can not say, at what time what button or link is clicked. So the "control" of what's happening is no longer at the program, it's at an outer source. The "control" has been inverted. The function is no longer "acting" it is instead "listening". Think of the hollywood principle: "Don't call us, we call you". A listener is a good example for a realisation of this pattern.
IoC is realized by functions or "methods" in the "object oriented world" of today.
"Dependency Injection" now means the same, but not for "methods", which do something, but for "objects", which hold data.
The data is no longer part of the object holding it. It is "injected" into the object at runtime. To stay in hollywood, think of a film star, playing golf to talk about the business, but to keep in shape, she hungers herself down, minimizing her muscle weight and therefore she is only able to carry one club at a time.
So, on the golf course her game would heavily depend on the one club, she is carrying.
Lucky for her, there are caddies, carrying a whole lot of clubs at one time, and also having the knowledge what club to use at what time. Now she is independent of her limited possibility to carry golf clubs. "Don't think about a concrete club to wear, we know them all and give you the right one at the right time".
The film star is the object and the golf clubs are the members of the object. That's dependency injection.
Maybe focus on the "injection" part? When I see that term, I think of syringes. The process of pushing the dependencies of a component to the component can be thought of as injecting into the component.
Just like with the body, when there is something that it needs in the way of medicine (a component that it needs) you can inject it into the body.
In their 2003 JavaPolis presentation (slides), Jon Tirsén & Aslak Hellesøy had an amusing analogy with a Girl object that needs a Boy to kiss. I seem to remember that the BoyFactory is sometimes known as a 'nightclub', but that's not in the slides.
Another analogy: let us say you are a developer and whenever you like you order computer science books from the market directly - you know the sellers and their prices. In fact your company might have a preferred seller and you contact them directly. All this works fine but may be a new seller is now offering better prices and your company wants to change the 'preferred' seller.
At this point you have to make the following changes - update the contact details (and other stuff) so as to use the new seller. You still place the order directly.
Now consider we introduce a new step in between, there is a 'library' officer in the company and you have to go through him to get the books. While there is a new dependency, you are now immune to any changes to the seller: either the seller changes mode of payment or the seller himself is changed, you now simply put an order to the librarian and he gets the books for you.
From Head First Design Patterns:
Remember, code should be closed (to change) like the lotus flower in the evening, yet open (to extension) like the lotus flower in the morning
A DI-enabled object can be configured by injecting behaviors defined in other classes. The original object structure doesn't have change in order to create many variations. The injection can be made explicit by having a class request other worker-classes in its constructor, or it can be less obvious when using monkeypatching in dynamic languages like Python.
Using an analogy of a Person class, you can take a basic human framework, pass it a set of organs, and watch it evolve. The Person doesn't directly know how the organs work, but their behaviors confirm to an expected interface and influence the owner's physical and mental manifestation.
A magician's sleight of hand! What you may think you see may be secretly manipulated or replaced.
Life is full of dependency injection analogies:
printer - cartridge
digital device - battery
letter - stamp
musician - instrument
bus - driver
sickness - pill
The essence of Inversion of Control (of which Dependency Injection is an implementation) is the separation of the use of an object from the management thereof.
The analogy/example I use is an engine. An engine requires fuel to run, i.e. it is depdendent on fuel. However, the engine cannot be responsible for the fuel it needs. It just 'asks' for fuel, and it is provided (typically by a fuel pump in a car).
The analogy starts breaking down when you look too deep, in that an engine doesn't ask for fuel, it is given it by some kind of management element, like an ECU. One might be able to compare the ECU to a container but I'm not certain how valid this is.
Your project manager asks you to write an app.
You could just write some code based on your career experience so far, but it's unlikely to be what your PM wants.
Better would be if your PM dependency injected you with say a spec for the app. Now your code is going to be related to the spec he gives you.
Better if you were told where the source repository was.
Better if you were told what the tech platform was.
Better if you were told when this needed to be done by.
Etc..
I think a great analogy is a six-year-old with a lego set.
You want your objects to be like the lego bricks. Each one is independent of all the others, and yet offers a clear interface for connecting them to the others. When connecting them together, it doesn't really matter exactly which two bricks you hook together so long as they have a matching interface.
Your dependency injection framework is like the six-year-old. He follows the instructions (i.e., your config file, annotations, etc.) to connect specific bricks together in certain ways to make a particular model.
Of course, since the bricks' interfaces are pretty generalized, they can go together in lots of different ways, so it's easy to come up with new sets of instructions which the six-year-old can use to make a completely different model out of the same bricks.