NerdonRails

Ja sorry das oder hätte ich nicht schreiben dürfen. Notfalls hätte man sich noch an den Threadtitel orientieren können.

Meine Ansprüche an ein "Projektverwaltungstool":

==> Anzeigen aller Projekte mit status (fertig, nicht fertig)

==> Informationsanzeige (welche Sprache, IDE Version, eventuelle Deadlines, Version, Projektoutput, zusätzliche Vermerke, eventuelle Ressourcen vermerke (wenn beispielsweise mehrere Leute dran arbeiten --> Gantdiagramm), Titel, Referenzen)

==> Möglichkeit das Projekt direkt aus der Anwendung zu starten

==> Interner Explorer der mir bei der detailansicht des Projektes die möglichkeit bietet den rootpfad des Projektes zu durchforsten und einzelne Dateien daraus zu starten.

==> Logische Verknüpfungen von Projekten.

Das heißt. Wenn das Programm verschiedenen Versionen von Projekten im Projekteordner endeckt soll es nur die neuste Version in der Liste anzeigen und die älteren bei der Detailansicht in einer History anzeigen.

==>Natürlich darf da auch nicht die Möglichkeit fehlen Dokumentation mit Projekte zu Verknüpfen (erstellen, bearbeiten, etc.)

Dann könnte man noch über ein Modul nachdenken das Ressourcen über einen Server mit anderen Projektteilnehmern shared, aber das wäre denke ich für erste zuviel und doch eher optional .

Ich hör lieber mal mit den Aufzählungen auf, da ich endlos so weiter machen könnte und das beim besten willen kein "tool" mehr wäre. Aber im Prinzip gibts da noch maßig Ausbaumöglichkeiten.

lg

Gateway

smells like Team Foundation Server mit Sharepoint-Integration

Will du deine ersten Programmiererfahrungen wirklich mit einer Sprache machen, die ausschliesslich einem Paradigma unterliegt, und dann auch noch das objektorientierte Paradigma ist?

Wenn du dich mit objektorientierter Programmierung beschaeftigen willst, dann lern' zuerst die grundlegenden Konzepte wie Rekursion/Iteration und Konditionalien kennen. Worauf ich hinaus will: Wie willst du den Sinn von Polymorphie als Substitut von Kontrollstrukturen wie IF verstehen, wenn du den Umgang mit derselben noch nicht gewohnt bist?

Meine Empfehlung an dich ist PHP, weil du schnell zu sichtbaren Ergebnissen, beispielsweise im Browser, kommst und den Umgang mit in nahezu allen Programmiersprachen vorkommenden Konzepten kennenlernst. Das wird dir als Anfaenger gefallen, weil du dich mit Zeigern nicht vorerst nicht beschaeftigen wirst und mit Datentypen fuer's erste nur grundlegend beschaeftigen musst.

Das OOP steht dir mit PHP immer frei. Du kannst sogar daselbe Problem in zwei Fassungen loesen und dabei die Unterschiede verdeutlichen.

Wenn du programmieren lernen willst, dann kommt es nur minder auf die Sprache an. Entscheidend ist, was du implementieren willst und welche Sprache mit welcher Syntax und welchen Paradigmen deinen Vorstellungen entspricht.

Somit betrachte ich es als laecherlich in der Java-Dokumentation nach dem optimalen Objekt fuer eine Array-Implementierung zu suchen, wenn einem noch nicht einmal das Konzept Array an sich verstaendlich ist.

PHP ? Hab ich den Witz nicht verstanden ?

Java ist schon recht, eine strutkurierte Sprache mit der man auch so ziemlich alles machen kann, und meines erachtens Magnituden besser als PHP.

ich werfe mal IronJS in den Raum, eine Javascript-Implementierung in F# die auf der DLR aufsetzt, evtl gehts damit

Ich würde das ganze via Rekursion lösen:

var rootElements = acc.GetRootElements(allItems);

var result = acc.BuildTree(rootElements, allItems);

public class Item

{

	public Int32 Id

	{

		 get;

		 set;

	}


	public Int32? ParentId

	{

		 get;

		 set;

	}


	public List<Item> Children

	{

		 get;

		 set;

	}


	public Item(Int32 id, Int32? parentId = null)

	{

		 this.Id = id;

		 this.ParentId = parentId;

	}

}

public class TreeAccumulator

{



	public IEnumerable<Item> GetRootElements(IEnumerable<Item> allItems)

	{

		 var rootElements = from current in allItems

					  where current.ParentId == null

					  select current;

		 return rootElements;

	}


	public IEnumerable<Item> BuildTree(IEnumerable<Item> itemsToBeProcessed, IEnumerable<Item> allItems)

	{

		 foreach (var current in itemsToBeProcessed)

		 {

			  var children = from actual in allItems

					  where actual.ParentId == current.Id

					  select actual;

			  current.Children = children.ToList();

			  this.BuildTree(current.Children, allItems);

		 }

		 return itemsToBeProcessed;

	}

}

Einfach die Spalte als Identity definieren und gut ist.

Ist das nicht das selbe Verfahren wie bei jeder anderen "normalen" Methode, die ein object (per Referenz) als Parameter entgegennimmt ?

z.B

public static void Normal_Refresh(ref UIElement uiElement)

   {

      uiElement.Dispatcher.Invoke(new Action(() => {}), DispatcherPriority.Render);

   }

Nein, Extension-Methods kann man im Gegensatz zu normalen Methoden wie von dir Aufgeführt auf ein Objekt aufrufen. Also sowas wie myTreeView.Refresh() anstatt MyStaticClass.NormalRefresh(myTreeView). Syntaktischer Zucker der zu besserer Lesbarkeit beiträgt. Weiterhin bieten Extension-Methods die möglichkeit, Klassen, die sealed sind um Methoden zu erweitern. So könnte man z.B. Int32 um eine IsEven()-Method erweitern.

public static class Extensions

{

      public static Boolean IsEven(this Int32 value)

      {

             return value % 2 == 0;

      }

}


2.IsEven() // => true

Weiterhin wäre das ref bei deiner Methode nicht nötig, da alles bis auf Datentypen die von Struct ableiten (Int32, Double, enums etc.) Referenzdatentypen sind.

Das liegt daran das DoEvents der fiese weg ist eine Forms-Applikation reaktiv bleiben zu lassen auch wenn der Thread mit krams ausgelastet ist, sprich die Form reagiert / wird dann neu gezeichnet und friert nicht ein. Bei einer Konsolen-Applikation muss nichts neu gezeichnet werden, zumindest nicht in der Art wie bei Forms-Applikationen. Deswegen ist DoEvents auch nur im System.Windows.Forms-Namspace vorhanden, dessen Assembly bei Konsolenanwendungen jedoch nicht referenziert wird da unnötig.

public static class ExtensionMethods

{

   public static void Refresh(this UIElement uiElement)

   {

      uiElement.Dispatcher.Invoke(new Action(() => {}), DispatcherPriority.Render);

   }

}

Evtl. mit dem Code oben das element neu rendern.

die frage ist ja nur, zu welchem Zweck?

Wie bei allem was nur begrenzt Sinn ergibt gilt folgendes: weil mans kann

Ok, dann werfe ich folgendes in den Raum:

Die Exe als Launcher und der Rest wird in DLLs verpackt die dann via IoC (z.B. Microkernel) zur Laufzeit nachgeladen werden. Das dürfte dem noch am nächsten kommen.

Nagut nun habe ich mich so lange damit beschäftigt jetzt möcht ich wenigstens wissen wie es funktioniert, das man eine exe wie oben beschrieben in den RAM packt und ausführt.

Indem man das Programm ausführt.

Was im danach im Speicher passiert steht hier: C# Heap(ing) Vs Stack(ing) in .NET: Part I

Sonstige Stichworte: C, Pointer, Heap, Stack

IL, ByteCode, CaaS => Google

CLR With C#, Third Edition => Amazon

no problem

Pseudocode:


public static void main(){


DatabaseConnectionA connA = DatabaseConnectionFactory.GetConnection("A");

DatabaseConnectionA connB = DatabaseConnectionFactory.GetConnection("B");

DataTransformator transformator = TransformatorFactory.GetTransformator();


DatabaseAdapterA adapterA = DatabaseAdapterFactory.GetAdapter(connA);

DatabaseAdapterB adapterB = DatabaseAdapterFactory.GetAdapter(connB);


EmployeeCollection employeeCollection = adapterA.RetrieveAllEmployees();

TransformedCollection transformedEmployeeCollection = transformator.PutDataInShapeForAdapterB(employeeCollection);


adapterB.StoreAllEmployees(transformedEmployeeCollection);

}

[/PHP]

Ok, meine Idee wäre eine Continuation.

Folgende API würde mir da einfallen und auch gefallen:

[PHP]
DatabaseConnectionA connB = DatabaseConnectionFactory.GetConnection("B");
DatabaseAdapterB adapterB = DatabaseAdapterFactory.GetAdapter(connB);

var myDataOperation = adapterB.StoreAllOfType<Employee>().WithDataFrom<DatabaseAdapterA>().Using<DataTransformator>();

myDataOperation.Execute();

adapterB würde dir hier z.B. ein StoreAllContinuation-Objekt zurückgeben das WithDataFrom() zur Verfügung stellt welches eine DataCollectContinuation zurückgibt die dann mit einem instanzierten DataTransformator die Daten aufbereitet und der ersten Continuation zur Verfügung stellt.

Be der Komposition der Klassen ist dann etwas Phantasy und Arbeit gefragt.

Die Lösung dürfte dann aber sauberer, wiederverwendbarer und besser lesbarer sein.

service ist nicht gleich webservice.

Über "Add ServiceReference" können meines wissens nach nur soap-services direkt konsumiert werden, da nur soap dinge wie objekt-metadaten zu objekt-serialisierung mitliefert (ok, VS versteht da auch OData, mein Fehler)

Also entweder einen entsprechenden WCF-Soap-Service erstellen und den dann mit VS-Boardmitteln konsumieren, oder z.B. einen Rest- oder OData-Service via WCF schreiben und den dann evtl manuell verarbeiten oder einen Windows-Service schreiben der auf einem bestimmten Port auf eingehende verbindungen hört und den ganzen kram von nochmal von Hand nachimplementieren.

render :partial => 'editCustomer', :customer => @customer

<% form_for :customer, customer, :url => { :controller => "customers", :action => "editCustomer", :remote=> true } do |f| %>


	<%= f.label :name %><br />

	<% if @customer != nil %>

		<%= f.text_field :name %>

	<% else %>

		Objekt ist Nil

	<% end %>

<% end %>

Ist aber ein sauberer Ansatz

MSDN hilft mir nicht wirklich weiter, mein Problem ist das ich in einem Test, Testsätze erstelle, die aber danach eig. wieder löschen will - damit ein anderer Test auch funktioniert.

Das klingt für mich nach Tests

Wenn du unit-tests gegen mit Linq2Sql oder EF fahren willst, würde ich dir empfehlen, den Datenkontext zu mocken. Der Datenbank-Ansatz ist ab einer gewissen Test-Anzahl einfach nicht mehr performant genug um die Test mehrmals am Tag laufen zu lassen.

Als erstes braucht man dafür ein Objekt das Mock-Objectset dastellt:

public class MockedObjectSet<T> : IObjectSet<T>

		 where T : class

	{

		public MockedObjectSet(List<T> entityList)

		{

			if (entityList == null)

			{

				throw new ArgumentNullException("entityList");

			}

			else

			{

				repository = entityList.ToList();

			}

		}


		IList<T> repository;


		#region IObjectSet<T> Members


		public void AddObject(T entity)

		{

			repository.Add(entity);

		}


		public void Attach(T entity)

		{

			this.AddObject(entity);

		}


		public void DeleteObject(T entity)

		{

			repository.Remove(entity);

		}


		#endregion


		#region IEnumerable<T> Members


		public IEnumerator<T> GetEnumerator()

		{

			return repository.GetEnumerator();

		}


		#endregion


		#region IEnumerable Members


		System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()

		{

			return repository.GetEnumerator();

		}


		#endregion


		#region IQueryable Members


		public Type ElementType

		{

			get { return typeof(T); }

		}


		public System.Linq.Expressions.Expression Expression

		{

			get { return repository.AsQueryable<T>().Expression; }

		}


		public IQueryProvider Provider

		{

			get { return repository.AsQueryable<T>().Provider; }

		}


		#endregion


		#region IObjectSet<T> Members



		public void Detach(T entity)

		{

			this.DeleteObject(entity);

		}


		#endregion

	}

Danach eine kleine extension die das erstellen des Mock-Objektes übernimmt:

public static class MockExtensions

	{

		public static IObjectSet<T> AsObjectSet<T>(this List<T> entities) where T : class

		{

			return new MockedObjectSet<T>(entities);

		}

	}

Als nächstes muss man aus der Klasse die von ObjectContext erbt ein Interface extrahieren. Das Interface wird benötigt um, z.B. in meinem Fall mit RhinoMocks, ein gemocktes Objekt zu erstellen.

IDatabaseEntitiesContainer context = MockRepository.GenerateStub<IDatabaseEntitiesContainer>();

List<Customer> customersList = new List<Customer>() { customer };

IObjectSet<Customer> customers = customersList.AsObjectSet();


context.Stub(stub => stub.Customers).Return(customers);

Über den gemockten Context kann man nun in aller Ruhe, nachdem man ihn mit Daten befüllt hat, linq-queries und Datenbank-Operationen testen ohne eine Datenbank anpacken zu müssen.

dreist

Stichwort: Kommandozeilen-Argument ?

Also für das Erstellen von Emails haben sich für mich XSLT-Templating & XSLT-Transformation als hervorragende Lösung herausgestellt.

XSLT-Transformation sollte auch für das Erstellen von Textdateien funktionieren.

Im Zweifel:

public void MyMethod<GenericParameter>()

{

            string s = "";

            Type t = s.GetType();

            List<GenericParameter> l = new List<GenericParameter>();

}

Ansonsten kann man generische Datentypen per Reflection erstellen. Siehe How to: Examine and Instantiate Generic Types with Reflection

falls du linq in verbindung mit sqlite benutzen möchtest, gibt es hier: LINQ with SQLite (linqtosql) - Stack Overflow

eine ganze Reihe an Providern (Closed & Open Source)

ich würde dir statt sqlite, wenn es denn lokal sein muss, lieber zum SQL Server Compact raten, da man so technlogisch im Microsoft-Raum bleibt und nicht externen kram einbinden muss.

SQL Server Compact gibt einem dann, ebenso wie sqlite, eine lokale Datenbank.

Referenz: Entity Framework (SQL Server Compact)

Und wenn du ganz verzweifelt bist nimm Access.