|
The real inefficiency comes from the memory management in the second instance. With your original code there is an object in memory already and this line
this.CurrentUser.Companies[idx] = comp;
simply copies the memory address of "comp" to the Companies array at index idx. However this code;
this.CurrentUser.Companies[idx].BusinessName = comp.BusinessName;
Looks at the length of comp.BusinessName, reserves the same amount of memory elsewhere, copies the contents of BusinessName into that memory, then assigns that memory address to Companies[idx].BusinessName. All that memory management makes that operation slow, and you are doing it multiple times.
There is nothing wrong with the dispose event being called, it doesn't make the code inefficient. Unnecessary memory management is more likely to be a cause of inefficiency.
|
|
|
|
|
COBOL has a MOVE CORRESPONDING that accomplishes what you want.
Internally, the compiler will still generate "4 moves". Why do you think that is?
And what part is "disposable"?
And how exactly is your code "calling Dispose"?
Or, are you bluffing?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
The Properties > Publish page of my App shows a Publish Version of 5.0.0.7.
When I use:-
Assembly assembly = Assembly.GetExecutingAssembly();
FileVersionInfo fileVersionInfo = FileVersionInfo.GetVersionInfo(assembly.Location);
it always gives 1.0.0.0.
How do I access the version number from the properties page?
|
|
|
|
|
public string AssemblyTitle
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyTitleAttribute), false);
if (attributes.Length > 0)
{
AssemblyTitleAttribute titleAttribute = (AssemblyTitleAttribute)attributes[0];
if (titleAttribute.Title != "")
{
return titleAttribute.Title;
}
}
return System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().CodeBase);
}
}
public string AssemblyVersion
{
get
{
return Assembly.GetExecutingAssembly().GetName().Version.ToString();
}
}
public string AssemblyDescription
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyDescriptionAttribute), false);
if (attributes.Length == 0)
{
return "";
}
return ((AssemblyDescriptionAttribute)attributes[0]).Description;
}
}
public string AssemblyProduct
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyProductAttribute), false);
if (attributes.Length == 0)
{
return "";
}
return ((AssemblyProductAttribute)attributes[0]).Product;
}
}
public string AssemblyCopyright
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyCopyrightAttribute), false);
if (attributes.Length == 0)
{
return "";
}
return ((AssemblyCopyrightAttribute)attributes[0]).Copyright;
}
}
public string AssemblyCompany
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyCompanyAttribute), false);
if (attributes.Length == 0)
{
return "";
}
return ((AssemblyCompanyAttribute)attributes[0]).Company;
}
}
Note that is the Executing Assembly it fetches data for - i.e. the assembly that that specific code is compiled into. If that is a DLL used by the app - i.e. a code library - it will fetch the data for the DLL, not the original EXE that called it. For the original EXE assembly data, replace GetExecutingAssembly with GetEntryAssembly
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
AssemblyVersion still returns 1.0.0.0 despite the Properties > Publish page showing 5.0.0.7. That is with GetExecutingAssembly or with GetEntryAssembly.
Am I missing something?
|
|
|
|
|
Probably, yes. From here though it's difficult to tell what. 
Start by looking in the project Properties folder at the file AssemblyInfo.cs - copy and paste that so we can read it, along with the full path to the file - the version info is normally at the bottom.
Then show exactly the code you used, what it displayed, and tell us the location of the file it's in (the full path helps here as well)
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks, got it. I am getting the correct details from AssemblyInfo.cs.
I'll just have to update that and not rely on the automatically incremented Publish Version as on the Properties > Publish page. I'll keep looking for a way to increment the former.
|
|
|
|
|
I will develop a new application with this specification:
read only from a folder (txt, xml, csv)
read only from a given database
generate files (txt, xml)
read and write from/to another database
communicate with printing server
communicate with email server
connect to a Web Service (Migration)
I think that the best approache is DDD (or hexagonal) maybe both but I have some questions:
1- DDD vs hexagonal (I can't find the real difference)
2- parsing files like txt, csv ... must be in the infrastructure layer that's mean we must use the repository pattern but how?
3- I have only read for some data sources so why we don't use the CQRS pattern (Read model / Write model)
4- the new web service will provide us the same data as a txt file so how could test our app and hide the data sources?
5- how Anti-Corruption Layer pattern can be used for this migration (cvs,txt ---> web service)
|
|
|
|
|
For a trivial app, you're over-thinking this. Start with some "DFD's" (Data Flow Diagrams).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Basically, I agree with Gerry Schmitz that your question is a case of bringing up a lot of accidental complexity into question.
1. The goal of DDD is to model a complex domain with a lot of business rules. From your specs it doesn't sound like you have a complex business domain. It doesn't sound like you have a domain at all, what you do is just a couple of CRUDs and printing/sending emails.
2. How does something put into the infrastructure layer means that you MUST use a repository pattern? Why do you have to use repository pattern at all? There is a lot of argument that having a repository atop of ORM (if you plan to use one) is a leaky abstraction. Building repository atop of csv, txt generation? Sounds even more questionable.
3. Practicing CQRS means increasing the cost of synchronization between your read and write models? Why is it worth it? To practice DDD, which is the original motivation for CQRS?
4. Basically, you can test it with on a lot of different layers, namely e2e, integration, unit tests.
5. Anticorruption layer means that you have to protect your complex business domain during the integration with legacy service. Do you have a complex business domain worth protecting? I doubt it.
|
|
|
|
|
thx.
the application is a banking app.
it will deal with:account, customers, transactions and other
banking products.
I agree with Gerry Schmitz. I started with DFD and the business logic.
As I said before, I will perform a reading from different
types of data sources(db and file system) this is my app domain.
And for business domain: banking rules, control, security, continuity.
infrastructure:
- repository pattern (EF dbcontext) and uow
- repository for file system (helper parsers )
- repository for Web Services
web services and file system having the same output/input business logic.
DB for saving and checking.
Finally to enssure the continuity we have to process the older (File system) and the newer
data sources (Web service)
|
|
|
|
|
Thanks for clarifying. I believe for modeling some complex business domain like banking system DDD makes sense and what you've provided in your clarification post is a sound approach.
|
|
|
|
|
I'm hoping this is possible in C# as I'm currently starting to learn C#
A black box is a box that you don't know what is inside but you can feed the box data and get a result. The black box has conditions. For example you might have an black box called age where you feed in a persons age and the result is "Under age" is displayed.
I want to have a number of black boxes in a program where once the black box code is written then I can forget about the code in the black box. All I need to do is to feed the black box information and get a result.
I'm thinking that this can be done with the C# class system or maybe there is a better way.
Maybe this setup is possible with an "age" black box and an "account" black box:
age person1 = new age
account person1 = new account
etc
Brian
|
|
|
|
|
Start with a class for each box, and if you want a "true" black box, put those classes in a separate Assembly. That way, you can release the Assembly .DLL file and add a reference to that in your other code with no source code required.
The "black box" code can't be changed without the source, and if you really want to you can use an obfuscator to make the DLL file a lot harder to examine.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks OriginalGriff for your reply.
The purpose of having black boxes was not to protect the code but to make it easier to program and I could use one or more black boxes when writing another program.
I don't know a lot about DLL type fiies but are you saying put the black boxes into a DLL and have the program refer to the DLL file...or maybe have a DLL for each black box?
Brian
|
|
|
|
|
Either way. If they are related function, then the same assembly makes sense. If not, then separate them by functional groups.
A DLL file (a class library in Visual Studio) is a .NET file which is compiled and is identical to an EXE file, except it lacks an entry point (the "Main" function).
By putting black box code in a separate assembly, you release the compiled file and the inner workings can't be seen or changed by the users. Much the same as you don't normally look at or try to modify the mechanics of the string.Substring method in your code (though you can access the Reference Sources if you want a look at how .NET does it).
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks for the info OriginalGriff.
I might have a closer look at how dll files are created in C#.
Brian
|
|
|
|
|
A "black box" is a "component" (class) with a "clean" explicit interface.
There are specific "properties and methods" (class members) that are explicitly made public for the sole purpose of interfacing with the component.
Contrast this with a component where EVERY member is simply defaulted to public so that there is no control over how the "internals" of the component are accessed.
It's a design strategy.
"Black Boxes" can be / have static members, much like the "Math" class.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Hi Gerry.
One of the reasons to have black boxes is to keep the code cleaner rather than have pages of code I can refer to the black boxes in my code which reduces the amount of code written.
It's a bit like not having to write a lot of code when you want text printed to the screen in C# you just need to type Console.WriteLine ("").
If I was to write a text adventure program in c# then one of the black boxes would handle the players inventory.
As I'm new to C# what type of things should I be looking for that point me in the wright direction and would help me create black boxes.I have books on C# and some reference on the internet.
Brian
|
|
|
|
|
You're talking about "modules" in general and confusing it with the "black box" (concept) which has to do with "interfacing" and "hiding" module "internals".
On the surface they all look the same; it's the design (or lack thereof) of the interface that differentiates them.
Contrast this with a "white room" where designers come up with new products, (supposedly) "isolated" from the risk of "stealing" from other people's products.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I call them black boxes as that's the best way to describe them.
To me a black bode is some code that's not in the main program but can be called then needed.
Having black boxes reduces the amount of code that is written as the rest of the code is in black boxes.
I cam across a example program recently where the main program calls another program to do a check and display the status. The program it called to me would be a black box as the code for the called program does not appear in the main program.
example:
//Main Program
dante.checkTemperature
dante.showAttributes
I'm wondering if there is a limit to the number of black boxes I can have in a program and how I would refer to a certain black box as the code above is for one black box.
Brian
|
|
|
|
|
So I've been working with making my windows form app work on multiple monitors such as centering my progress dialog on the screen that the app is running on using the Screen Device Name, running some math and setting the parameters to center the dialog window. So this works fine when the app starts on the monitor, but when I move the app to another monitor, the Screen device name remains the same.
I'm trying to figure how to update the Screen device name when you move the app to another monitor.
Searching the web so far has produced nothing because I don't even know what to call this.
But I will start with the Screen class after this and see what I can dig up.
So far I've been able to save the App's window parameters so that it opens again on the right monitor, if the app is closed in a minimum state I can make it normal and open on the correct monitor.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
Maybe my issue is a flawed thought in how I calculate this. I used the device name because I wasn't able to do the math on the primary monitor.
public ProgressDialog()
{
InitializeComponent();
this.AutoScaleMode = AutoScaleMode.Dpi;
this.AutoSize = true;
Screen myMonitor = Screen.FromControl(MainForm);
this.StartPosition = FormStartPosition.Manual;
this.Top = (myMonitor.WorkingArea.Height / (double)2) - (this.Height / (double)2);
if ((myMonitor.DeviceName.Contains("DISPLAY1")))
this.Left = myMonitor.WorkingArea.Width / (double)2 - (this.Width / (double)2);
else
this.Left = myMonitor.WorkingArea.Right - (myMonitor.WorkingArea.Width / (double)2) - (this.Width / (double)2);
Console.Write("Stop");
}
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
I just writing this in case I need to go back and figure it out again. So far it works pretty good but I'm sure there's a better way of doing this. Well the idea is that if you have multiple displays, 2 or 3 running horizontal, and you keep moving the app around to a different monitor, or overlapping 2 monitors, and you want to get your progress dialog centered in the application. I tried a whole of ways of doing this, but the parameters I saved on the main form when changed, would not update when accessing it from the progress dialog.
So I took my global class and added a Rectangle to it. I wrote this in VB but used this forum to ask the question.
Friend Module Global360
Public Property GOnline As Boolean
Public Property MfRectangle As Rectangle
End Module
Then on the MainForm in the Event Location Changed, I added this
If mainForm.WindowState = FormWindowState.Minimized
Global360.MfRectangle = Rectangle.Empty
Else
Global360.MfRectangle = Nothing
Global360.MfRectangle = new Rectangle(mainForm.Left, mainForm.Top, Me.Width, Me.Height)
Application.DoEvents()
End If
And in the Progress Dialog, I wrote this in Form New
If (Global360.MfRectangle <> Rectangle.Empty) Then
Me.StartPosition = FormStartPosition.Manual
Me.Top = ((Global360.MfRectangle.Height - Me.Height) / 2) + Global360.MfRectangle.Y
Me.Left = ((Global360.MfRectangle.Width - Me.Width) / 2) + Global360.MfRectangle.X
Else
Me.StartPosition = FormStartPosition.CenterScreen
End If
I'll change the code as soon as I get it working in C#
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
If you get this working "too well", you'll find that if you don't keep ALL your monitors on, the app will wind up "displaying" on a monitor that you don't have access to (if that's where it last displayed).
It shows in the Task Bar but that doesn't help in moving it (again).
(Same thing happens with UWP because it does all the "location saving and restoring" for you).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
