I load resources in groups. Loading a resource has 3 steps, (1) streaming in the raw data, (2) parsing/initializing it, and (3) resolving links between resources.
Step 1 is handled by the file system and 2/3 by the specific factories. As soon as the data is streamed in, the factory performs step 2. During step 2, you can request more resources to be loaded (such as your textures) -- if you do this, they're added to the same "loading group". Only once every resource in a group has completed steps 1&2, then step 3 is performed for each resource in the group.

You probably want to be carefull in how you construct your load units, so that they load only what you need got that unit. Dependency checks in your bundle build step can alleviate these issues, so that you only bundle resources that are often used together. This will remove your problems in that the load unit has to be loaded completely.

My target is to load raw data, then initialize them(creating textures, xml documents, shaders etc.) and then release them. But there is a problem, if models come before textures. I'm having two solutions now:
1) Organizing files to load textures before models
2) Load model, then give a request for texture and if texture is loaded, then send it to every model which want it
But, isn't here a better way(I want to support multithreaded programming)?
It's a good way to loading resources asynchronously?

One option is to allow request handles, so resource A can refer to as-yet-unloaded resource B. When you want to load a texture, you immediately create a new engine-side Texture object and assign it to the model's member variable as appropriate. This handle doesn't actually yet refer to a real texture; it either refers to some kind of empty texture or a placeholder missing texture. The texture can load in the background. Objects with dependencies should keep track of how many of their dependencies are still pending and leave themselves in a pending stuff until the dependencies are resolved.

I've seen approaches that use multiple layers of indirection, so e.g. you are given a pointer to a RequestHandle which in turn points to a Resource (so you have to m_MyResource->GetResource()->Foo() to interact with the resource). I dislike this approach, though it certainly works (even on Very Large Games). I prefer allowing resources to be streamed in such that every request for a resource directly and immediately returns an instance of that specific resource type, which just also handles state and dependent loads (possibly via a Resource base class). Either approach works just fine with threads, though it's definitely easier in the first approach.

A further advantage of this system is that you _can_ allow use of the handles before they're fully loaded. This can represent Level of Detail objects (you're not done streaming in the whole resource, but a portion of it is ready; see how Unreal textures stream in, for instance). It also makes it easier during development to deal with missing resources; just have the handle refer to the "missing" default instance of the resource type until-and-if the load completes. You may find during early iterations you want to get into game as quickly as possible to test various features and don't care whether certain resources load immediately or at all, while of course in release builds you want every resource to be ready before you exit any loading screens. Loading groups, pending states and dependent loads, and post-load callbacks all make it easy to deal with when and if you need to. If resource A needs data from resource B, a post-load step allows you to fix up data once all the dependent loads are complete.

You can build bundles on top of this system, of course, as well as all other kinds of pre-loading and prioritization systems. The above isn't a full solution, but it has some advantages (especially in the short-mid term of development). It also plays nicely with loose assets, which is handy either during early development or if you plan to allow easy and ubiquitous modding (like Bethesda's RPGs, for instance).